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.