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.
