Storing a pointer in a reference type seems absurd to me. Matt
On Friday, December 29, 2017 at 11:07:31 PM UTC-6, Matt Harden wrote: > > 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 <javascript:>> 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...@googlegroups.com <javascript:>. >> 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.
