'Use tagged literals for struct initializations'... I'd rather the compiler help me make sure i've updated all uses appropriately when I add a new field.
Sometimes you don't use the field everywhere. Instead you add a new field to extend a functionality, with a proper new method/function. So if you use tag literals your existing code will still compile safely, and the tests will pass too (assuming you didn't change the functions where the struct were used).
In a very large code base, not using tagged literals will just break anything. Not sure you want it (for the case of extending). Removing will already break it so no problems there.
Say I have 3 members that must be set, and 5 optional members. Go's solution is to make the 3 critical members private so that someone using this struct will probably figure out they should use a construction function. And doing this means replacing all code that creates my struct with calls to a 'New' function. With all this friction, people aren't likely to do the right thing.
At least in C++ with public members I can initialize appropriately in the constructor. Of course littering my code-base with public members would be bad practice in the first place.
I used to worry about that, too, but in practice it rarely causes problems. The constructor function will be grouped with the type it returns in Godoc, and auto-complete generally will show both type Foo and func NewFoo when you start typing "Foo". And generally you place the constructor function next to the type it creates in the code as well.... it all contributes to it not really being a problem.
Because you don't agree with this: http://golang.org/doc/go1compat ? And there is even an example of how a new field called `Zone` was introduced and not using tagged literals would break the existing code. I don't understand why you said I stopped reading despite these both two facts just written there.
It is reckless to suggest that one can arbitrarily add fields to structs because they've used tagged literals with the implication that this won't bite people with difficult to find default value errors down the line. It's a poor solution to a problem that's far better handled with a constructor function.
It's not reckless. Go has zero values for a reason. When writing code, you need to take into consideration what it means if one or more of the values in your struct is set to the zero value. It's pretty trivial to say "ok, I added this new field Foo. If Foo is the zero value, do the same thing the code used to to before Foo existed". Then your package will be 100% backwards compatible for people that used struct literals. Obviously, that's not always possible, but often times it is.
Look, suppose you go ahead and follow this advice instead of using a constructor function. What have you got?
First, you'll have to update each-and-every single function that operates on the struct to deal with zero-values with ambiguous semantics (i.e. is it zero because that's meaningful in my domain, or is it zero because Johnny forgot to update the allocation). If you'd used a constructor function, then you could've resolved the meaning of those default values and been done with it.
Second, the next time you add a new field, you'll have to deal with a potentially complex interplay between default values and what the code actually needs to do.
Third, the absence of compiler errors fails to notify third-party users of your library how the semantics of your struct has changed, with all of the long-nights-of-debugging that that will entail.
