On Wednesday, June 4, 2025 at 12:18:26 PM UTC+8 Axel Wagner wrote:
On Tue, 3 Jun 2025 at 22:17, tapi...@gmail.com <tapi...@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. As a basic rule, we should never use *ZeroSizeType as error types. Just use ZeroSizeType as error types. 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...@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/39f6abe2-3cd9-4cd0-8998-44cf5157df8bn%40googlegroups.com.
