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 page

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 oppos

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 s

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 i

Re: [go-nuts] Is introducing ... to parameter list a breaking change? How is it considered in the proposal process?

Hi Axel and Ian, Thanks for the elaborative answer! I was too naive while considering the case and didn't observe the existing practices well. Assignability seems to create a lot more complicated compatibility issues. Regarding the compatibility promises to users, it always seems the interpret

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

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 e

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

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 tho

Re: [go-nuts] Refactor to use generics to have a single Make

On Wednesday, May 4, 2022 at 7:01:48 AM UTC+8 se...@liao.dev wrote: > right now it only works if the structs are actually identical: > https://go.dev/play/p/tMG3SYG5fLN > > - sean > > Though accessing fields is still not allowed. > > On Tue, May 3, 2022 at 8:06 PM sbezverk wrote: > >> Hello,

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 i

Re: [go-nuts] Refactor to use generics to have a single Make

right now it only works if the structs are actually identical: https://go.dev/play/p/tMG3SYG5fLN - sean On Tue, May 3, 2022 at 8:06 PM sbezverk wrote: > Hello, > > > > I am starting to learn generics and I was wondering if the following code > could be refactored to use genercis, in order to a

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

Re: [go-nuts] Refactor to use generics to have a single Make

On Tue, May 3, 2022 at 12:06 PM sbezverk wrote: > > > I am starting to learn generics and I was wondering if the following code > could be refactored to use genercis, in order to avoid using per type Make() > method. > > > > https://go.dev/play/p/gE4Z6Zj19Is > > > > I have 3 identical structs,

Re: [go-nuts] Is introducing ... to parameter list a breaking change? How is it considered in the proposal process?

On Tue, May 3, 2022 at 12:28 PM Changkun Ou wrote: > > I wonder how the Go project defines a breaking change, specifically for the > case where we have an existing API but want to add ... to its parameter list > for customizations. > > For instance, we have an API: > > package foo > func Bar() {

Re: [go-nuts] Is introducing ... to parameter list a breaking change? How is it considered in the proposal process?

Basically every change to any exported API is a breaking change , strictly speaking. For this case, a user might do var f func() = pkg.Bar Which would fail to compile if `pkg.Bar` gains variadic arguments. Similar constructs

[go-nuts] Is introducing ... to parameter list a breaking change? How is it considered in the proposal process?

Hi gophers, I wonder how the Go project defines a breaking change, specifically for the case where we have an existing API but want to add ... to its parameter list for customizations. For instance, we have an API: package foo func Bar() {} And the current code uses this function as: foo.Bar

[go-nuts] Refactor to use generics to have a single Make

Hello, I am starting to learn generics and I was wondering if the following code could be refactored to use genercis, in order to avoid using per type Make() method. https://go.dev/play/p/gE4Z6Zj19Is I have 3 identical structs, they are defined with different types and used in other t

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