Re: [go-nuts] Generic "nillable" constraint

Oh (sorry, being forgetful) and re "it's less of a new mechanism than introducing a zero identifier": #62487 introduces *even less* new mechanism, by expanding comparison to (and assignment of) `nil` to all types inside a generic function. It's not a new

Re: [go-nuts] Generic "nillable" constraint

(correction: It should be Convert[J isinterface, T J]. I changed the name from I to J to be more readable and then missed one occurrence) On Wed, Oct 4, 2023 at 7:33 AM Axel Wagner wrote: > On Wed, Oct 4, 2023 at 6:54 AM Jon Watte wrote: > >> > where it is important to permit only type argument

Re: [go-nuts] Generic "nillable" constraint

On Wed, Oct 4, 2023 at 6:54 AM Jon Watte wrote: > > where it is important to permit only type arguments that can be compared > to nil > > I see! As in, if we somehow got a "equalszero" constraint, then that > constraint would solve the problem I illustrate. > I believe that assertion is correct,

[go-nuts] Re: Is there a race in exec.CombinedOutput?

>From the Stdout/Stderr field documentation on the os/exec.Cmd type : "If Stdout and Stderr are the same writer, and have a type that can be compared with ==, at most one goroutine at a time will call Write." On Tuesday, October 3, 2023 at 9:55:16 PM UTC-4 王富民awa

Re: [go-nuts] Generic "nillable" constraint

> where it is important to permit only type arguments that can be compared to nil I see! As in, if we somehow got a "equalszero" constraint, then that constraint would solve the problem I illustrate. I believe that assertion is correct, but I also believe that is a stronger assertion, and also tha

[go-nuts] Is there a race in exec.CombinedOutput?

exec.CombinedOutput uses the same io.Writer for both stdout and stderr in exec.go - Go (opensource.google) . This io.Writer is written in exec.go - Go (opensource.google)

Re: [go-nuts] Generic "nillable" constraint

On Tue, Oct 3, 2023 at 5:57 PM Jon Watte wrote: > > > Can you give us an example? > > I already gave examples! They're in the thread! In reality, we have the > insides of a compiler where this would be helpful in more complex cases, and > we have the insides of a graphql and JSON web interface w

Re: [go-nuts] Generic "nillable" constraint

> Can you give us an example? I already gave examples! They're in the thread! In reality, we have the insides of a compiler where this would be helpful in more complex cases, and we have the insides of a graphql and JSON web interface where this would be helpful in a more complex case, but I'm not

Re: [go-nuts] Generic "nillable" constraint

> It's not obvious that that is an interesting set of types. How often > do people want to write a generic function that permits any type that > can be compared to nil but does not permit any numeric or string type? Well I've run into this with some frequency, and a bunch of other developers here

Re: [go-nuts] Generic "nillable" constraint

On Tue, Oct 3, 2023 at 9:06 PM Jon Watte wrote: > I don't want to include int or struct{} in this case. I care specifically > about "can be compared to nil" > The only thing I can do with a type parameter that is only constrained as > "nil" is compare it to nil, or assign nil to it. > This means

Re: [go-nuts] Generic "nillable" constraint

On Tue, Oct 3, 2023 at 12:06 PM Jon Watte wrote: > > I don't want to include int or struct{} in this case. I care specifically > about "can be compared to nil" > The only thing I can do with a type parameter that is only constrained as > "nil" is compare it to nil, or assign nil to it. > This me

Re: [go-nuts] Generic "nillable" constraint

I don't want to include int or struct{} in this case. I care specifically about "can be compared to nil" The only thing I can do with a type parameter that is only constrained as "nil" is compare it to nil, or assign nil to it. This means approximately "any reference type" -- interfaces, pointers,

Re: [go-nuts] Re: Is it expected that signal.NotifyContext() changes the execution thread?

Almost all graphics systems are single threaded. Some allow additional non rendering event loops but with heavy restrictions that GUI components are only accessed on the main event loop thread. > On Oct 3, 2023, at 2:00 AM, 'wagner riffel' via golang-nuts > wrote: > > On Tue Oct 3, 2023 at

Re: [go-nuts] Re: Is it expected that signal.NotifyContext() changes the execution thread?

On Tue Oct 3, 2023 at 05:54 AM UTC, Kurtis Rader wrote: > Thank you to Ian and TheDiveO. I don't understand why functions like > gocv.io/x/gocv.NewWindow() have to run on the initial OS thread (at least > on macOS). It's common for C and C++ libraries to use TLS (thread local storage) to attach d