I really wish Go had not chosen to propagate Hoare's billion-dollar mistake. I do realize it's all tied up with the idea that initialization is cheap and zero values should be useful when possible, and therefore pointers, interfaces, channels, etc. need zero values.
I wonder how different Go would have been if we had required all pointers and interfaces (only) to be initialized, and made the zero value for maps a writable empty map. In cases where nil pointers and interfaces are useful, it seems to me that sentinel values would serve the purpose equally well. For example, comparing errors with (ok) would be (one character) shorter, more meaningful and less confusing than comparing with nil, which can be so confusing for newcomers that we have an FAQ for it. Few would be surprised to find (e != ok) when (e == (*myerror)(nil)) -- and if there were no nil pointers, it wouldn't even be a valid question to ask. We could still use pointers as stand-ins for Optional types, just with sentinel values like sql.NullInt64 to serve the purpose nil does. I know this is likely a non-starter for Go2, for good reasons - virtually all Go code would need significant, probably manual refactoring, and interoperability with other languages would suffer, to name two that come to mind. I think what I really want is Haskell plus all the benefits Go has relative to it, including Go's incredibly simple language spec, standard library, short compile times, etc. Is that too much to ask? :-) On Fri, Nov 3, 2017 at 9:30 AM <oju...@gmail.com> wrote: > This thread helped me to understand better the current scenario and the > implications of a future change. > > I would be glad to recognize if this conversation had changed my mind, but > it didn't. > > Some programmers discovered that they could use this "valid nil interface" > to do some smart tricks, as Jakob kindly has shown. While I do recognize > that was indeed smart, Jakob offered another easy way of attaining the > desired effect for his constructor. It would be pretty easy if he had to > code that way to begin with. > > I consider unfortunate the fact that I can't safely use an interface where > previously I used a pointer. To me, at least, that is a natural > evolutionary path for a piece of software as soon as the developer discover > opportunities to leverage the commonality of an interface. I think such > possibility would be more broadly useful than what we can do now. > > Go has a bunch of interesting tricks and useful idioms, but this trick is > proving costly. > > Thanks to everyone. > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
