* Functions: Compare the corresponding memory addresses. The time
complexity is constant.
There are cases involving closures, generated trampolines, late
binding and other details that mean that doing this will either
eliminate many optimization possibilities or restrict the compiler too
much or cause surprising results. We disabled function comparison for
just these reasons. It used to work this way, but made closures
surprising, so we backed out and allow comparison only to nil.
* Maps: Compare the corresponding `*runtime.hmap` (pointer) values.
The time complexity is constant.
* Slices: Compare the corresponding `runtime.slice` (non-pointer
struct) values. The time complexity is constant.
In LISP terms, these implementations do something more like `eq`, not
`equal`. I want to know if the slices or maps are _equivalent_, not if
they point to identical memory. No one wants this semantics for slice
equality. Checking if they are equivalent raises difficult issues
around recursion, slices that point to themselves, and other problems
that prevent a clean, efficient solution.
Believe me, if equality for these types was efficient _and_ useful, it
would already be done.
-rob
On Tue, May 3, 2022 at 2:41 PM Will Faught <will.fau...@gmail.com> wrote:
>
> You seem to have misunderstood the point. It's an idea for changing the
> language. You're just demonstrating the current behavior, which is what would
> be changed. The argument is to make `make([]int, 2) == make([]int, 2)` legal,
> and evaluate to false.
>
> On Mon, May 2, 2022 at 8:22 PM Kurtis Rader <kra...@skepticism.us> wrote:
>>
>> On Mon, May 2, 2022 at 7:44 PM will....@gmail.com <will.fau...@gmail.com>
>> wrote:
>>>
>>> ```
>>> type Slice1000[T any] struct {
>>> xs *[1000]T
>>> len, cap int
>>> }
>>>
>>> func (s Slice1000[T]) Get(i int) T {
>>> // ...
>>> return s.xs[i]
>>> }
>>>
>>> func (s Slice1000[T]) Set(i int, x T) {
>>> // ...
>>> s.xs[i] = x
>>> }
>>>
>>> var xs1, xs2 [1000]int
>>>
>>> var a = Slice1000[int]{&xs1, 1000, 1000}
>>> var b = Slice1000[int]{&xs2, 1000, 1000}
>>> var c = a == b
>>> ```
>>>
>>> Do you expect `c` to be true? If not (it's false, by the way), then why
>>> would you expect `make([]int, 2) == make([]int, 2)` to be true?
>>
>>
>> No. Did you actually try your hypothetical `make([]int, 2) == make([]int,
>> 2)`? When I do so using the source below this reply the Go compiler emits
>> the error "slice can only be compared to nil". Which is what I expect given
>> the specification for the Go language. This seems like an example of the XY
>> Problem. What caused you to open this thread?
>>
>> package main
>>
>> import (
>> "fmt"
>> )
>>
>> func main() {
>> fmt.Printf("%v\n", make([]int, 2) == make([]int, 2))
>> }
>>
>> --
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAKbcuKheNk99JrYJ8u6knu15LSwf6nZXxD6_UqUOF_1JhFVHjA%40mail.gmail.com.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOXNBZRFShduyB7QYxVgwJa6GA7NbK6eO1i3ETps1f3nQRQVCw%40mail.gmail.com.
