I was being facetious. You have the right to opine, but elevating opinions to that of proofs doesn't give the discussion any utility. I think you should consider the underlying assumptions in some of your points:
1. A slice is a descriptor of an aggregate 2. A struct can resemble a descriptor of an aggregate. 3. A struct can resemble a slice 4. If a slice can be compared as a struct holding a descriptor, then maps can have slices as keys 5. Because it benefits this use case, it is a good feature to add to the language Enumerating the drawbacks of this feature is more useful than trying to justify its existence. The language authors omitted this functionality for a reason. One of the reasons is that arrays and slices are similar, and changing their comparison semantics seemed confusing. On Sunday, July 3, 2016 at 11:32:39 AM UTC-7, Chad wrote: > > Pardon? > > On Sunday, July 3, 2016 at 8:13:30 PM UTC+2, as....@gmail.com wrote: >> >> Hardcoded proofs should be assigned well-named identifiers. If you ever >> have to alter them, you don't want to be rummaging around your lemmas and >> corollaries. >> >> On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote: >>> >>> 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.
