Ok. That "haha" was merely to show that no animosity was borne. And also because you didn't really answer the question as I asked (by quoting the spec) which I found funny.
Alas, I guess we couldn't see eye to eye. But chill a little bit. I have given all the hardcoded proofs and people have just given me *feelings* about what they thought should be right. I think I have the right to disagree. Anyway, I can only wish you good continuation. :) On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote: > > 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.
