On Tue, 3 Jun 2025 at 22:17, tapi...@gmail.com <tapir....@gmail.com> wrote:
> Or better, use ErrType instead of *ErrType, so that no need to declare the > global error var. > Doing that is problematic. If the `Error` method is declared with a value receiver, it is promoted to the pointer-type as well. At that point, it is no longer a priori clear, whether you should type-assert to `ErrType` or `*ErrType`. Or similarly, which to use with `errors.As`. Likewise, it is possible to assign either to `error`, so it is easy to accidentally return the wrong type. This can lead to very hard to find bugs, as error-paths tend to not be well tested anyways. This doesn't happen with pointer receivers, as they are not promoted to the value type. So any mixup gets statically caught by the compiler. So, as a general rule, an often type-asserted interface like `error` should be implemented using pointer-receivers. > > > > On Tue, 3 Jun 2025 at 17:56, tapi...@gmail.com <tapi...@gmail.com> wrote: > > > > On Tuesday, June 3, 2025 at 8:58:10 PM UTC+8 Bushnell, Thomas wrote: > > Why do you think these are incorrect uses of errors.Is? If you are only > testing the Boolean value, Is is fine and the same as As; you should only > use As if you are actually going to use the identified error value in some > way. > > Because errors.Is mainly use == to compare errors. When the errors are > pointers to zero-size values, the comparison result is compiler dependent, > as the whole thread is talking about. > > Maybe using errors.As is also not a good idea for such cases. Such cases > just need an errors.OfType[ErrType]() alike function. > > > > > *From:* golan...@googlegroups.com <golan...@googlegroups.com> *On Behalf > Of *tapi...@gmail.com > *Sent:* Monday, June 2, 2025 3:14 PM > *To:* golang-nuts <golan...@googlegroups.com> > *Subject:* Re: [go-nuts] Comparison of pointers to distinct zero-sized > variables > > > > This message was sent by an external party. > > > > > > On Sunday, June 1, 2025 at 11:21:28 PM UTC+8 Oliver Eikemeier wrote: > > > Am 27.06.2024 um 05:17 schrieb Ian Lance Taylor <ia...@golang.org>: > > > > On Tue, Jun 25, 2024 at 9:37 PM 'Axel Wagner' via golang-nuts > > <golan...@googlegroups.com> wrote: > >> > >> you might be interested to learn that Ian has filed a CL adding an FAQ > entry. > > > > Now committed at https://go.dev/doc/faq#zero_size_types . > > > > Ian > > Thanks for that. I discovered that comparing pointers to ZSTs is pretty > popular in Go: > > - x/sync/singleflight: > https://cs.opensource.google/go/x/sync/+/refs/tags/v0.14.0:singleflight/singleflight_test.go;l=78 > > - Delve: > https://github.com/go-delve/delve/blob/v1.24.2/service/debugger/debugger.go#L387 > > - Grafana: > https://github.com/grafana/grafana/blob/v12.0.1/pkg/services/serviceaccounts/extsvcaccounts/service.go#L353 > > - Skaffold: > https://github.com/GoogleContainerTools/skaffold/blob/v2.16.0/pkg/skaffold/hooks/render.go#L93 > > - Coder: https://github.com/coder/coder/blob/v2.22.1/cli/ssh.go#L578 > > - quic-go: > https://github.com/quic-go/quic-go/blob/v0.52.0/connection_test.go#L1008 > > - SigStore Cosign: > https://github.com/sigstore/cosign/blob/v2.5.0/cmd/cosign/cli/attest/attest_blob_test.go#L60 > > Seems like a classic example of Hyrum's Law, we now have a lot of code > that depends on runtime.zerobase. > > > > It looks all of bad code (using errors.Is) should use errors.As instead. > > This indeed reflects that the design of the errors APIs is prone to being > misused. > > > > An "errros/v2" is really needed to avoid such misuses. > > > > > > I’ve written a linter along with an accompanying blog post about the > subject: > > fillmore-labs.com/zerolint: https://github.com/fillmore-labs/zerolint > > “The Perils of Pointers in the Land of the Zero-Sized Type”: > https://blog.fillmore-labs.com/posts/zerosized-1/ > > > I would be interested whether I got the “default” level right. Or maybe > everything wrong. > > Thanks for the insight, again > Oliver > > -- > 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...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/7750b85c-2e09-4e42-a290-480b81caf19dn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/7750b85c-2e09-4e42-a290-480b81caf19dn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/06eef021-6d5b-496c-898f-bdd375453b35n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/06eef021-6d5b-496c-898f-bdd375453b35n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- > 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 visit > https://groups.google.com/d/msgid/golang-nuts/d9b53c59-1d53-49bc-98e0-5d0b587b5705n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/d9b53c59-1d53-49bc-98e0-5d0b587b5705n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFYkvgdzHmDdyCPG_EM5eUoj5AegLSxbqz1xZSznv31dg%40mail.gmail.com.
