On Fri, Jul 1, 2016 at 4:01 PM, Chad <send2b...@gmail.com> wrote: > > > On Friday, July 1, 2016 at 3:44:10 PM UTC+2, Martin Geisler wrote: >> >> On Fri, Jul 1, 2016 at 12:52 PM, Chad <send...@gmail.com> wrote: >> > However, that it's a valid point you raise (re strings) >> > But that's exactly the reason for which, someone would probably ask >> > whether >> > a string is a reference type or a value type. >> > >> > This could probably made clearer in the documentation. >> >> I keep seeing references (hah!) to this concept of a "reference type" >> :-) However, I just tried searching the language spec and Effective Go >> and there doesn't seem to be such a concept defined in those >> documents. > > > I think it should. It is mentioned here however > https://blog.golang.org/go-maps-in-action
You're right, that article calls maps, slices and pointers "reference types". I feel that is a little unfortunate since it muddles the picture and makes the implementation more obscure. I would have been happy to have been told right from the start that a slice is a small struct, small enough that you can pass it by value instead of with a pointer. That allows me to build a mental model in terms of other Go constructs. It might very well be that a slice isn't implemented *exactly* like a struct, but if the mental picture of a struct explains the behavior and performance characteristics, then it doesn't matter if the compiler somehow cheats here and there when implementing the type. > Without that, one of the first instinct of beginning programmers is often to > create pointers to slices. > I feel that, more clarifications about this area of the language would help > a lot instead. > > This is also a terminology of PLT that exists in other languages but as > usual, one has to be careful about the implementation false friends. I agree, "reference type" is a widely used term. I think I prefer to use it only for pointer types such as *int, *byte and so on. Everything else would be value types, including string, map[int]int, []float and other special builtin types. When talking about equality, the language defines some of these types as comparable, with per-type rules for how == is implemented. Relaxing the rules to allow comparing slices (by pair-wise comparison of the values in the slices) seems like a natural thing to do for me. It would make slice comparison work like string comparison works currently. So the rule for comparison would not even be new or strange -- just a natural extension of what is already there. You could probably also make slices (and arrays) ordered, provides the elements themselves are ordered. That would work the same way strings work today: lexicographic ordering based on the elements. -- Martin Geisler -- 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.
