In fact, that is somewhat my fault. I should ask:
What is a slice? What is an array? Spoiler: a slice is a reference type in its "wikipedia-ish" definition (auto-dereferencing) which is the reason you observe such a result in the playground. On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote: > > No. You should not get it from here. You should get the answer from the > spec. Let alone the fact that the implementation should ideally follow the > spec and not the reverse. > > On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote: >> >> If I look at what %v means, print out the values of various types in Go, >> according to https://golang.org/pkg/fmt/ then I believe that this holds >> the answer: https://play.golang.org/p/GiLckoBDxa >> >> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote: >>> >>> Not for comparison. >>> >>> I am just asking what is the value of a slice and what is the value of >>> an array. >>> >>> Remember that there is no slice comparison that has been spec'ed so far. >>> >>> On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote: >>>> >>>> For []T the value of a slice for the purpose of comparison would be >>>> each individual value compared against each-other (ofc maybe comparing the >>>> length first as an optimization). >>>> Same goes for an array. >>>> >>>> And again, you are missing the whole point. Both me and you are wrong >>>> in each-others points of view. >>>> Just accept this. >>>> >>>> On Sunday, July 3, 2016 at 11:19:48 AM UTC+1, Chad wrote: >>>>> >>>>> What's the value of a slice? >>>>> >>>>> What's the value of an array? >>>>> >>>>> On Sunday, July 3, 2016 at 12:05:38 PM UTC+2, Florin Pățan wrote: >>>>>> >>>>>> If the type is *[]T then comparing memory addresses make sense to see >>>>>> if both terms point to the same memory address. >>>>>> If the type is []T then comparing memory addresses doesn't make sense >>>>>> as I'd expect to compare values. >>>>>> Finally, if the type is []*T then I'd still expect to compare values >>>>>> (even if this is inconsistent with the above two rules), mainly because >>>>>> I'm >>>>>> usually interested in the values a slice holds. >>>>>> >>>>>> And that's exactly why Ian and others said this is complicated to >>>>>> define as different users expect different outcomes. >>>>>> So rather than deal with this, in an auto-magic way, better let the >>>>>> users deal with it as they see fit from case to case. >>>>>> >>>>>> On Sunday, July 3, 2016 at 10:53:39 AM UTC+1, Chad wrote: >>>>>>> >>>>>>> Which is why it should be formalized. >>>>>>> >>>>>>> Where is the inconsistency between slices and arrays? >>>>>>> Why do people even think that a slice need to behave like an array >>>>>>> wrt equality, were it introduced? >>>>>>> >>>>>>> A slice is not an array! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sunday, July 3, 2016 at 11:36:44 AM UTC+2, as....@gmail.com >>>>>>> wrote: >>>>>>>> >>>>>>>> Relaxing unformalized behavior makes little sense to me. Explaining >>>>>>>> why equality is inconsistent between slices and arrays is not >>>>>>>> something I >>>>>>>> want to do either. >>>>>>>> >>>>>>>> >>>>>>>> On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote: >>>>>>>>> >>>>>>>>> Rob and Robert actually wrote that this area of the spec needs >>>>>>>>> more work... >>>>>>>>> Otherwise, the behaviour of maps, slices and funcs cannot be fully >>>>>>>>> explained. >>>>>>>>> >>>>>>>>> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as....@gmail.com >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Go does not have reference types. As far as I know, the word was >>>>>>>>>> purposefully removed from the spec to remove the ambiguity >>>>>>>>>> surrounding the >>>>>>>>>> word. >>>>>>>>>> >>>>>>>>>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> @Martin >>>>>>>>> >>>>>>>>> As I've mentioned earlier, one ought to be careful about false >>>>>>>>> friends from other languages. >>>>>>>>> I am not sure I understand what you mean by: >>>>>>>>> >>>>>>>>> if the name field is changed after the call >>>>>>>>> >>>>>>>>> >>>>>>>>> -- 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.
