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.
