I'm sorry but your attitude is counterproductive to the discussion. "haha" what? I told you I see your point, I think I know the specs very well, thank you for the link. However, you seem incapable of accepting, despite an number of others saying the contrary, despite, given a reasonable example where even the standard library gets this "wrong" (according to you, according to me it's exactly as it should be). You've been explained several times that both point of views hold valid arguments so why do you insist your point of view is the only correct one and everyone else is wrong? The authors of the language which have far more experience that me (I can't speak for your experience or others), couldn't get to an agreement on how this should work so they took the best decision, let the user deal with this according to their individual needs. I'll stop following this thread / replying as it's pointless to do so at this point. Good luck proving everyone else is wrong and you know better.
On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote: > > Ok, Let me help you out haha :) > > Here is the definition of a slice. It is not a container. > https://golang.org/ref/spec#Slice_types > > I am not inventing things. > > I know what people on this thread said, but that's their misconception. > > On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote: >> >> As you pointed out, Printf() should follow the ref spec but that doesn't >> happen because some humans don't perceive this accuracy as necessary or >> maybe because the way to resonate about slices / arrays is as containers >> for the actual values. >> Thus we have Printf working as it does (and %p will indeed print the >> memory address of the slice type). >> >> I would definitely want to be able to compare []int{1, 2, 3} with >> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example >> purposes but think of them as coming from different sources) >> Apparently you don't, and that's fine. >> >> That's exactly why the compiler only allows comparison with nil, to force >> the user to think about that should be compared, not do it by default and >> have potential hidden issues that might be uncovered too late in the >> process. >> >> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote: >>> >>> 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.
