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.
