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.
