Since an interface can be nil I’ve been assuming interface behaves like slice with a pointer to the concrete data within a reference struct (that also includes the data type) which is passed around as an interface var.
This playground shows that the interface var is a similar reference type to slice: https://play.golang.org/p/PIWpyrpwNq5 I didn’t know where to look in the Go source to find the definition of an interface (src/runtime/type.go, src/runtime/iface.go, src/go/types/type.go, and src/cmd/compile/internal/types/type.go weren't immediately clear to me). The specification says an interface stores a value; my misunderstanding is that while the interface var may refer to data elsewhere, this data is a copy of the original. So using a pointer assigned to an interface as a way to save stack space is absurd, but using a pointer assigned to an interface as a way to modify the original data does make sense. Arguing about nil interface vs nil pointer in an interface is not absurd, I apologize for my statement. Matt On Saturday, December 30, 2017 at 1:22:37 PM UTC-6, Matt Harden wrote: > > 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 <matthe...@gmail.com <javascript:>> 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...@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.
