Yeah, if I could go back in time and tweak Go, removing the idea that zero values should generally be "valid" and that anyone the ability to name an exported type should be able to create a zero value of that type would be pretty high on my list of priorities. Not the highest, but it's up there.
I think it's one of those ideas that makes sense at first because it's easy to come up with examples of objects that can be constructed legally as zero values, and then convince yourself that maybe we live in a world where most values can be so constructed. The standard library has a number of them. However, I find the techniques for constructing them gas out long before the problem is solved. Unfortunately, it's the sort of thing that only really becomes proved once the language goes 1.0 already.
However, in pretty much any language, it's hard to avoid the user having some ability to fill out even "mandatory" fields in some invalid manner. You can impose terrifically strong typing on a value, but if the user wants to slap a "0" into the Price field "just to get the object constructed", there's not a lot you can do to stop them in the end. Or, if "0" is forced to be invalid, 0.01 or some other value. Programmers can be quite creative in pursuing bad ideas in their designs....
> However, in pretty much any language, it's hard to avoid the user having some ability to fill out even "mandatory" fields in some invalid manner.
I 100% agree. It's just that go seems to make it easier to make invalid values than valid ones, because the programmer doesn't have to actually type the values that end up invalid.
I think it's one of those ideas that makes sense at first because it's easy to come up with examples of objects that can be constructed legally as zero values, and then convince yourself that maybe we live in a world where most values can be so constructed. The standard library has a number of them. However, I find the techniques for constructing them gas out long before the problem is solved. Unfortunately, it's the sort of thing that only really becomes proved once the language goes 1.0 already.
However, in pretty much any language, it's hard to avoid the user having some ability to fill out even "mandatory" fields in some invalid manner. You can impose terrifically strong typing on a value, but if the user wants to slap a "0" into the Price field "just to get the object constructed", there's not a lot you can do to stop them in the end. Or, if "0" is forced to be invalid, 0.01 or some other value. Programmers can be quite creative in pursuing bad ideas in their designs....