I got the impression the proposal was motivated by scalars that did not currently allow `nil` values
Under the heading "Alternatives and why they're bad" he describes some ways this is currently dealt with - such as the common idiom of returning or passing a pointer to a value, instead of a plain value. (He didn't mention using an interface, incidentally - which doesn't have some of the downsides he described. For example, a plain numeric value wrapped in an interface can't be mutated) As has already been observed, if you're going to allow the full range of values of some type T (i.e. all possible bit patterns), *plus* the sentinel value of "unset", then you need an extra bit - which can be done using a struct, or by indirecting through a pointer or an interface. The problem that the OP has is that none of those options will force you to check the state of the extra bit, or that the pointer/interface is not nil - which could be argued is a problem with pointers/interfaces in general. But I think this is not really worth arguing. If you change fundamental things like this in the language, then you'll suggesting turning Go into something that looks like Rust. In which case, you may as well just use Rust. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b409e7bb-ef94-40db-986f-268643e7cb39n%40googlegroups.com.
