Re: [go-nuts] Add comparisons to all types

The proposal was declined, so no need to respond. Some responses inline below. Thanks so much for your feedback, Axel. :) On Thu, May 5, 2022 at 11:39 AM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Thu, May 5, 2022 at 7:32 PM Will Faught wrote: > >> Yeah, it's a

Re: [go-nuts] Add comparisons to all types

Yeah, it would have performance implications, which is a good counter argument. Regardless, it seems from the discussion that function values can have multiple addresses, so it wouldn't work currently anyway. On Thu, May 5, 2022 at 6:39 AM David Arroyo wrote: > On Mon, May 2, 2022, at 22:43,

Re: [go-nuts] Add comparisons to all types

On Thu, May 5, 2022 at 2:53 AM Axel Wagner wrote: > On Thu, May 5, 2022 at 3:11 AM Will Faught wrote: > >> The reason to include capacity in comparisons, aside from it being >>> convenient when doing comparisons, is that the capacity is an observable >>> attribute of slices in regular code.

Re: [go-nuts] Add comparisons to all types

On Thu, May 5, 2022 at 10:32 AM Will Faught wrote: > > I think what you've put forth as counter arguments are instead principles, > like "simplicity is good," "complexity is bad," "changes have cost," and so > on. Principles aren't themselves arguments, so they can't be used as premises > in

Re: [go-nuts] Add comparisons to all types

On Thu, May 5, 2022 at 7:32 PM Will Faught wrote: > Yeah, it's a trade-off. I can understand that it's not worth it. > I find it confusing to me that you seem to be willing to allow the existence of tradeoffs on the one hand. And on the other you treat most arguments as all-or-nothing

Re: [go-nuts] Add comparisons to all types

On Wed, May 4, 2022 at 1:00 PM Ian Lance Taylor wrote: > On Tue, May 3, 2022 at 11:01 PM Will Faught wrote: > > > > On Tue, May 3, 2022 at 7:27 PM Ian Lance Taylor wrote: > >> > >> Does a program like this print true or false? > >> > >> func F() func() int { return func() int { return 0 } } >

Re: [go-nuts] Add comparisons to all types

On Thu, May 5, 2022 at 3:39 PM David Arroyo wrote: > Go programs run on a single computer. What if a Go runtime was built that > ran Go programs across many computers? I don't think this would pose any problems to this topic specifically. It would pose many problems, but once you have them all

Re: [go-nuts] Add comparisons to all types

On Mon, May 2, 2022, at 22:43, will@gmail.com wrote: >- Functions: Compare the corresponding memory addresses. The time >complexity is constant. How would this apply to inlined functions? supporting equality would essentially force the compiler to keep a the function in the output

Re: [go-nuts] Add comparisons to all types

On Thu, May 5, 2022 at 3:11 AM Will Faught wrote: > The reason to include capacity in comparisons, aside from it being >> convenient when doing comparisons, is that the capacity is an observable >> attribute of slices in regular code. Programmers are encouraged to reason >> about slice capacity,

Re: [go-nuts] Add comparisons to all types

On Wed, May 4, 2022 at 10:10 PM Ian Lance Taylor wrote: > I can only give some personal opinions. Others will disagree. And my > opinions change over time, and could well be mistaken. > > I think that deciding that := declares a single variable in a > for/range statement was a mistake

Re: [go-nuts] Add comparisons to all types

On Wed, May 4, 2022 at 9:21 PM Will Faught wrote: > > Makes sense, although I chuckled when I realized that the creator of that > issue didn't actually have his issue resolved. I'll just note that I was the creator of that issue. Ian -- You received this message because you are subscribed to

Re: [go-nuts] Add comparisons to all types

Makes sense, although I chuckled when I realized that the creator of that issue didn't actually have his issue resolved. Creator: This behavior is undefined. Which one should it be? Go Team: Both.  On Wed, May 4, 2022 at 12:46 PM Ian Lance Taylor wrote: > On Tue, May 3, 2022 at 10:59 PM

Re: [go-nuts] Add comparisons to all types

I was only pointing out that if you use method based operations you can do whatever comparisons you find appropriate. > On May 4, 2022, at 8:19 PM, Will Faught wrote: > >  > I don't follow how that's related to slice comparisons, aside from that fact > that slice comparison could be a

Re: [go-nuts] Add comparisons to all types

I don't follow how that's related to slice comparisons, aside from that fact that slice comparison could be a method, but an Equals() method would be left out to be consistent with how it is today. On Wed, May 4, 2022 at 5:22 AM Robert Engels wrote: > Seems easier to move to a Go without

Re: [go-nuts] Add comparisons to all types

Can you explain what you mean by tokens? Do you mean something like: ``` var red, green, blue = new(struct{}), new(struct{}), new(struct{}) ``` If so, I don't see how that's useful. Why not use integers or bytes instead? On Wed, May 4, 2022 at 12:35 AM 'Dan Kortschak' via golang-nuts <

Re: [go-nuts] Add comparisons to all types

On Wed, May 4, 2022 at 12:13 AM Axel Wagner wrote: > On Wed, May 4, 2022 at 8:42 AM Will Faught wrote: > >> Yes. I understand what you suggested and I understood how it *would* >>> work, if implemented that way. But why is that the best way to compare >>> them? Doing it that way has a bunch of

Re: [go-nuts] Add comparisons to all types

On Wed, May 4, 2022 at 12:53 PM 'Axel Wagner' via golang-nuts wrote: > > On Wed, May 4, 2022 at 9:46 PM Ian Lance Taylor wrote: >> >> Zero sized values are useful in Go, because they can have methods and >> they can be stored in interfaces. But if the addresses of zero-sized >> values must be

Re: [go-nuts] Add comparisons to all types

On Tue, May 3, 2022 at 11:13 PM Jan Mercl <0xj...@gmail.com> wrote: > > On Wed, May 4, 2022 at 4:27 AM Ian Lance Taylor wrote: > > > In saying this I don't at all claim that Go is perfect. There are > > places where we made mistakes. > > May I please ask you to share what you personally consider

Re: [go-nuts] Add comparisons to all types

On Tue, May 3, 2022 at 11:01 PM Will Faught wrote: > > On Tue, May 3, 2022 at 7:27 PM Ian Lance Taylor wrote: >> >> Does a program like this print true or false? >> >> func F() func() int { return func() int { return 0 } } >> func G() { fmt.Println(F() == F()) } >> > > It would print false,

Re: [go-nuts] Add comparisons to all types

On Wed, May 4, 2022 at 9:46 PM Ian Lance Taylor wrote: > Zero sized values are useful in Go, because they can have methods and > they can be stored in interfaces. But if the addresses of zero-sized > values must be distinct, then although zero-sized values appear to > have zero size they must in

Re: [go-nuts] Add comparisons to all types

On Tue, May 3, 2022 at 10:59 PM 'Axel Wagner' via golang-nuts wrote: > >> As a tangent, I don't understand why this wasn't made unambiguous in the >> language spec. Why not have `new(struct{})` always allocate a new pointer? >> Who's allocating all these empty structs on the heap where this is

Re: [go-nuts] Add comparisons to all types

Seems easier to move to a Go without operators and do everything with functions and generics. This is essentially the Java model. This is pretty much the approach that the sync, sort, etc packages took and with generics you can have type safety and less code duplication. > On May 4, 2022, at

Re: [go-nuts] Add comparisons to all types

Well, I agree! :) Comparisons should be shallow where possible for every type, including slices and maps. That's my initial argument. On Tue, May 3, 2022 at 11:22 PM Jan Mercl <0xj...@gmail.com> wrote: > On Wed, May 4, 2022 at 12:15 AM Will Faught wrote: > > > I'm not sure we're on the same

Re: [go-nuts] Add comparisons to all types

On Tue, May 3, 2022 at 10:59 PM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Wed, May 4, 2022 at 1:40 AM will@gmail.com > wrote: > >> I don't think controversy is a good counterargument. It's vague, >> unquantifiable, and subjective. I could easily claim the

Re: [go-nuts] Add comparisons to all types

On Wed, May 4, 2022 at 12:15 AM Will Faught wrote: > I'm not sure we're on the same page in terminology. I meant shallow as > opposed to deep. E.g. pointer equality in terms of `==` vs. > `reflect.DeepEqual`. Unequal pointers can reference values that are > equivalent. I think we are on the

Re: [go-nuts] Add comparisons to all types

On Wed, May 4, 2022 at 4:27 AM Ian Lance Taylor wrote: > In saying this I don't at all claim that Go is perfect. There are > places where we made mistakes. May I please ask you to share what you personally consider a mistake and, if possible, what would you change if you can, say, travel back

Re: [go-nuts] Add comparisons to all types

As for documentation for how `func` works BTW: This design doc for Go 1.1 is a good description and AFAIK mostly up to date. It doesn't mention how inlining decisions and dynamic linking affect the pointer

Re: [go-nuts] Add comparisons to all types

On Tue, May 3, 2022 at 7:27 PM Ian Lance Taylor wrote: > On Tue, May 3, 2022 at 6:08 PM Will Faught wrote: > > > > My apologies, it seems that "reply all" in the Google Groups UI doesn't > send email to individuals like "reply all" in Gmail does, just the group. > Response copied below. > > >

Re: [go-nuts] Add comparisons to all types

On Wed, May 4, 2022 at 1:40 AM will@gmail.com wrote: > I don't think controversy is a good counterargument. It's vague, > unquantifiable, and subjective. I could easily claim the opposite, while > also giving no proof. > Sure. It was not intended to be an argument. It was intended to be an

Re: [go-nuts] Add comparisons to all types

On May 3, 2022, at 7:27 PM, Ian Lance Taylor wrote: > > Does a program like this print true or false? > > func F() func() int { return func() int { return 0 } } > func G() { fmt.Println(F() == F()) } > > What about a program like this: > > func H(i int) func() *int { return func() *int {

Re: [go-nuts] Add comparisons to all types

On Tue, May 3, 2022 at 6:08 PM Will Faught wrote: > > My apologies, it seems that "reply all" in the Google Groups UI doesn't send > email to individuals like "reply all" in Gmail does, just the group. Response > copied below. > >> Yes, it can. That's not the issue. The issue is that whether

Re: [go-nuts] Add comparisons to all types

On Tuesday, May 3, 2022 at 12:30:47 AM UTC-7 axel.wa...@googlemail.com wrote: > On Tue, May 3, 2022 at 8:32 AM Will Faught wrote: > >> Can't the same argument be made for pointer comparisons? >> > > I think what it comes down to is: Yes, this argument can be made for > pointers as well. But

Re: [go-nuts] Add comparisons to all types

I'm not sure we're on the same page in terminology. I meant shallow as opposed to deep. E.g. pointer equality in terms of `==` vs. `reflect.DeepEqual`. Unequal pointers can reference values that are equivalent. On Mon, May 2, 2022 at 11:58 PM Jan Mercl <0xj...@gmail.com> wrote: > On Tue, May 3,

Re: [go-nuts] Add comparisons to all types

On Mon, May 2, 2022 at 11:32 PM Will Faught wrote: >> >> 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

Re: [go-nuts] Add comparisons to all types

On Tue, May 3, 2022 at 8:32 AM Will Faught wrote: > Just as pointer comparisons are shallow, so too are comparisons for types > that contain pointers. Pointer comparisons are not shallow. Comparing two pointers compares the entire values. a == b and *a == *b compare different values but in

Re: [go-nuts] Add comparisons to all types

> > 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

Re: [go-nuts] Add comparisons to all types

* 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

Re: [go-nuts] Add comparisons to all types

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

Re: [go-nuts] Add comparisons to all types

On Mon, May 2, 2022 at 7:44 PM will@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 > } >

[go-nuts] Add comparisons to all types

All types should have unrestricted comparisons (`==`, `!=`), but a few pre-declared types don't. Adding them would bridge a semantic gap between pre-declared and user-declared types, enabling all types to be used as map keys, and otherwise make reasoning about them more consistent and