3 ms·

I'm not sure why it would be significantly better to have reliably "typed nil" over "untyped nil". The concept has no real definition to begin with: what matter

by temac 6y ago

I'm not sure why it would be significantly better to have reliably "typed nil" over "untyped nil". The concept has no real definition to begin with: what matters about sound typing are the static guarantees a type brings, or by association even if this not really the same concept, the "dynamic guarantees" about the behavior of objets of some "dynamic type" (that is the variable used as a handle to the objet had no guarenteed static type, but in most cases the object themselves have a type). Acting on a "type" of nil values seems to make very little sense. Maybe there are obscur constructs where this would be handy, but at the first glance I would consider it probably indicative of a dirty hack, and recommend looking for alternate solutions.

stcredzero 6y ago
In Smalltalk, nil was a constant that contained the only instance of the class UndefinedObject. What some people did, was to put methods on UndefinedObject to implement a "NullObject" pattern for their domain objects. Since everything is default initialized to nil, everything would just work. The big downside of this, were beginners putting methods on UndefinedObject that they should not have. There's a thin line of conceptual understanding between a bit-bucket that hides errors from you, and a useful NullObject. Some people would call this a "dirty hack" for that reason.
curryst 6y ago
It's probably not useful in Go's type system. It would be useful if there were union types, though. I sometimes end up using pointers for nullable fields because the zero values are significant in whatever domain I'm working in. I either have to make it a pointer, or I have to implement a new special zero value, or I have to make a struct that can keep track of whether a value has been set or not. It'd be nice to be able to do type MyStruct struct { ID int || nil } And have the compiler understand that the ID has to be either an int or nil, and to give me errors if I try to use it as an int without making sure it isn't nil.

by temac 6y ago

stcredzero 6y ago

In Smalltalk, nil was a constant that contained the only instance of the class UndefinedObject. What some people did, was to put methods on UndefinedObject to implement a "NullObject" pattern for their domain objects. Since everything is default initialized to nil, everything would just work. The big downside of this, were beginners putting methods on UndefinedObject that they should not have. There's a thin line of conceptual understanding between a bit-bucket that hides errors from you, and a useful NullObject. Some people would call this a "dirty hack" for that reason.

curryst 6y ago

It's probably not useful in Go's type system. It would be useful if there were union types, though. I sometimes end up using pointers for nullable fields because the zero values are significant in whatever domain I'm working in. I either have to make it a pointer, or I have to implement a new special zero value, or I have to make a struct that can keep track of whether a value has been set or not. It'd be nice to be able to do type MyStruct struct { ID int || nil } And have the compiler understand that the ID has to be either an int or nil, and to give me errors if I try to use it as an int without making sure it isn't nil.