I don't know what you mean by "reference type" - as I understand it, that's not a meaningful phrase in Go. Did you mean "interface"? If so, we store pointers in interfaces all the time in Go. When we set an interface variable i to x, we are semantically making a copy of x and storing it in i. We won't be able to modify x using i (because it has a copy of x, not a pointer to the original). If x is a pointer to something, then we *will* be able to modify that something using i.
On Sat, Dec 30, 2017 at 8:08 AM <matthewju...@gmail.com> wrote: > 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> 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. >> >> >>> 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. > -- 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.
