Re: [go-nuts] When are two channels equal?

On Tue, 2025-01-21 at 23:13 -0800, Jason E. Aten wrote: > I think comparable just means "will compile without error". Yes, this is the case. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails

Re: [go-nuts] When are two channels equal?

Thanks Dan. Also I was mixing up "comparable" and "actually being equal", as in == returning true. I think comparable just means "will compile without error". On Wednesday, January 22, 2025 at 7:10:10 AM UTC Dan Kortschak wrote: > On Tue, 2025-01-21 at 23:00 -0800, Jason E. Aten wrote: > > > >

Re: [go-nuts] When are two channels equal?

On Tue, 2025-01-21 at 23:00 -0800, Jason E. Aten wrote: > > So what is "the same make"? It's not the same make, it's the same *call* to make. So a := make(chan struct{}); b := a; if a == b { /* this executes */ }. -- You received this message because you are subscribed to the Google Groups "go

[go-nuts] When are two channels equal?

Reading https://go.dev/ref/spec#Comparison_operators , I come across the interesting but a little ambiguous definition of equality of channels: *"Channel types are comparable. Two channel values areequal if they were created by the same call to make orif both have value nil." (emphasis mine)*

Re: [go-nuts] Go 1.24 runtime.Cleanup and sync.Pool.

On Tue, Jan 21, 2025 at 6:10 PM John wrote: > > Curious if the new runtime.Cleanup() would allow auto sync.Pool.Put() for a > variable. I'm not sure from the documentation if this would work or would > cause some type of issue (the variable was on its way to collection and then > gets put in a

[go-nuts] Go 1.24 runtime.Cleanup and sync.Pool.

Curious if the new runtime.Cleanup() would allow auto sync.Pool.Put() for a variable. I'm not sure from the documentation if this would work or would cause some type of issue (the variable was on its way to collection and then gets put in a pool. I assume it would stop collection?). The guar

Re: [go-nuts] Re: Getting new coverage output format from go test -cover

Oh that's perfect! Pretty much what I was looking for. Let me test it and get back to you. I wonder where the blog author found that flag? It's not exposed in `go test` On Tuesday, January 14, 2025 at 5:27:07 AM UTC-8 Byungjun You wrote: > Have you try go test with -args -test.gocoverdir param

Re: [go-nuts] Go 1.24 BLooper

There was a lot of discussion of this on the proposal, starting with (and well summarized by) https://go.dev/issue/61515#issuecomment-1646194700. If we don't inline, there will be cases like yours that wanted to benchmark with inlining but don't get it. If we do inline, there will be cases that are

[go-nuts] patching std package inside vendored package?

Hi there, I would like to patch a package from the standard library in a large Go project. To be specific, I'd like to replace archive/tar in https://github.com/containers/podman. I can kludge this by creating my own version of the tar package, and patching up the imports across the vendor/ d

Re: [go-nuts] inconsistent min max signatures with variadics

ok. Thanks Ian and Dan for your explanations even if I understand that the reason is just an implementation reason which introduces a bias on unpacking operator (seperation of concern would have be great here I suppose but maybe less efficient). Le lundi 20 janvier 2025 à 23:54:43 UTC+1, Dan Ko

Re: [go-nuts] Example tests: access to module testdata files

That's a really helpful comment. I'll give the embed/fs.FS approach a go -- thank you. On 20/01/25, Sean Liao (s...@liao.dev) wrote: > The playground, which also serves pkg.go.dev examples. runs in an > isolated environment with just the built test/example binary, without > the source code. > Con