[yencabulator]

If there's a non-nullable type, then there's types without zero values, and that means some basic properties of Go no longer hold. I don't know how many times that can be said differently. Whether something is in a struct or not is not relevant.

[LudwigNagasena]

What basic properties no longer hold?

[yencabulator]

Uninitialized variables are zero. Composite literals may omit fields, and they'll be zero. Map accesses for nonexistent keys return zero values. Channel receives from closed channels return zero values. make returns zero-valued slices. Comma-ok style type assertions return zero values. Slices are fat pointers where the zero value avoids an allocation for data.

[LudwigNagasena]

That would still hold. Those things just wouldn’t be typed as non-nullable.

[yencabulator]

Now you're creating a flavor of types that cannot be used in many places. Or worse, a flavor of types that when added to a struct breaks existing uses. That'd be a major change.

[LudwigNagasena]

> Now you're creating a flavor of types that cannot be used in many places.

Yeah, that’s the entire point. Type safety.

[yencabulator]

Sigh. Yes, everyone knows what the goal is. But that goal is in conflict with the design decisions made in Go, and there's no clear path forward. You're not responding at all to the actual implications of types without zero values. There's no such thing as a "type that cannot be sent over a channel" or "a type that cannot be a map value" or "a type that when added anywhere in a composite type prevents omitting fields in composite literals" or "a type that cannot be comma-ok type asserted to". And it's highly unlikely such concepts will be added to the spec.

You'd have to start by constructing replacements for all those mechanisms, then migrate all Go source code in the world over to the new APIs, just to enable Go to have types without zero values.