On Saturday, July 2, 2016 at 10:23:04 AM UTC+2, Martin Geisler wrote: > > On Fri, Jul 1, 2016 at 4:01 PM, Chad <send...@gmail.com <javascript:>> > 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. >
A struct is considered a reference type if at least one of the field *points* to another object. (i.e. holds a reference to another object). https://en.wikipedia.org/wiki/Reference_type It's clearer. "small struct" would not be explicit enough nor true. I think that slices require typically more documentation effort to clarify what they are. Then, the issue of comparability will be obvious. There are user-defined reference types too. type Foo struct{ name string data *[192]byte } That would be a reference type. This one is comparable. > > 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.
