41–50 of 101 posts
Earlier quoted context omitted.
IMHO it should be a compiler error. This is just so loose... a wheel fell off.
A wheel is generous. This seems more like inviting the computing equivalent of spilling twenty thousand tons of crude into the sea, which then promptly catch fire.
Am I the only one who found the described behavior to be intuitively correct? I did expect it to print "abc.com".
Over the course of ~10 years of writing Go, my ratio of "embedding a struct" to "regretting embedding a struct" is nearly 1:1. I do not embed structs anymore. It is almost always a mistake. I would confidently place it in the "you should be required to import 'unsafe' to use this feature" bin.
Using struct embedding for pure data to implement discriminated unions is fine, better than MarshalJSON() that is lost on a type definition. Using it to save typing, or going crazy with it (I consider embedding two things going crazy) is bad.
Introduction of proper discriminated unions would be great.
My personal conspiracy is that Golang is an epic prank. Make a language that's really good in some ways and just horrible in other ways for no reason whatsoever. So that when it's critics point out contradictory features like embedding, it's defenders can be the ultimate troll and say things like "but, actually, it's a simple language because it doesn't have while loops". It's the best explanation I have for some of…
Am I the only one who found the described behavior to be intuitively correct? I did expect it to print "abc.com".
type Foo struct {
MyType MyType
}
myFoo.MyType.url
Earlier quoted context omitted.
A wheel is generous. This seems more like inviting the computing equivalent of spilling twenty thousand tons of crude into the sea, which then promptly catch fire.
Eh it’s about the same level of footgun you might see in C99. It’s not great but you’re being hyperbolic if you ask me.
https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug
Earlier quoted context omitted.
Using struct embedding for pure data to implement discriminated unions is fine, better than MarshalJSON() that is lost on a type definition. Using it to save typing, or going crazy with it (I consider embedding two things going crazy) is bad.
I think that using embedding for discriminating unions if a good idea. It would work, but it does not force the user to do the discrimination. I would say that explicit typecasting at the point of discrimination is safer. Without it, nothing prevents you from using one field from one variant of the union, and another from a different variant. Introduction of proper discriminated unions would be great.
type Order struct {
Type OrderType
CommonAttr1 int
CommonAttr2 string
}
type OrderTypeA struct {
Order
TypeAAttr1 int
TypeAAttr2 string
}
type OrderTypeB struct {
Order
TypeBAttr1 int
TypeBAttr2 string
}
You seem to be under the impression that I'm advocating for something like
type OrderUnion struct {
CommonAttr1 int
CommonAttr2 string
TypeAAttrs
TypeBAttrs
}