Yes. You're absolutely right.That's due to the current implementation of
strings.
Maybe they should be implemented as a struct with an unexported array of
byte
That would just work.
Having the string kind with the same structure as a slice is the problem
here. strings should probably be pure values.
In any case, that's still an issue of defining what a value type and a
reference type are.
The implementation is a guide but it should not influence the spec so much
as well.
slices are reference types and the comparison behaviour should be obvious:
it's determining whether they reference the same thing.
strings are value types and likewise, the comparison behaviour is obvious.
On Friday, July 1, 2016 at 3:35:01 PM UTC+2, Martin Geisler wrote:
>
> On Fri, Jul 1, 2016 at 12:48 PM, Chad <send...@gmail.com <javascript:>>
> wrote:
> > On Friday, July 1, 2016 at 12:11:43 PM UTC+2, Martin Geisler wrote:
> >>
> >> On Fri, Jul 1, 2016 at 3:15 AM, Chad <send...@gmail.com> wrote:
> >> > No, it's actually fine. You are comparing values.
> >> >
> >> > A slice being a struct under the hood, for slices you would compare
> the
> >> > structs (slice headers)
> >>
> >> Yes, when you remember that a slice is a just a small struct with a
> >> pointer and some bookkeeping information (length, capacity), then you
> >> can compare two slices easily. So with
> >>
> >> a := []int{10, 20, 30}
> >> b := a[:]
> >>
> >> then a == b would be fast: simply compare the pointers and the
> >> bookkeeping information. Direct value equality between the structs
> >> gives you the expected and correct answer.
> >>
> >> But what about
> >>
> >> []int{10, 20} == []int{10, 20}
> >>
> >> where the two slices refer to different underlying arrays? I think you
> >> argue that this comparison should be false?
> >
> >
> > Yes. And it is. A slice is not an array. Or an open-ended array.
>
> Right, a slice is just view into an array :-)
>
> I was hinting at the (lack of) symmetry with how strings work.
>
> Two strings that share no underlying memory can compare equal, so I
> think it would be reasonable if equality between slices followed the
> same principle. Put differently, strings are "magic" and don't follow
> normal rules for comparison, in particular, they don't use direct
> value comparison. Here I'm assuming that
>
> https://golang.org/pkg/reflect/#StringHeader
>
> shows us how strings are implemented: a small struct with a pointer
> and a length. If string comparison were to use value semantics, a and
> b could not compare equal in this little example
>
> a := "hello world"
> b := make([]byte, len(a))
> os.Stdin.Read(b)
>
> since the pointer in a would differ from the pointer in b. Yet a == b
> is true when you enter "hello world" :-) So we see the magic slip
> through the cracks...
>
> Given that, one could argue that it would be consistent to have
> []int{1} == []int{1} be true -- it's just yet another exception to the
> rule that things are compared by value. It's not super pretty, though,
> but I my opinion the illusion of prettyness has already been broken
> with how some builtin types get special treatment here and there.
>
> --
> Martin Geisler
>
--
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.
