While that works it's way more overhead than the pointer comparison that's currently needed and would need all constructors and uses to be updated in the code base.
On Sat, 22 Aug 2026 at 20:27, Sean Liao <[email protected]> wrote: > The vet warning is actually because of the embedded / promoted Error > method is found. > > Even though you can call .Error() on both HTTError and *HTTPError > (through automatic dereferencing) > HTTPError is not comparable to *HTTPError. > Which is what vet is warning about since it expects the type that > implements the error interface to be the canonical representation of > the error value. > > If you instead wanted to implement Is, then you have to make the value > type comparable: > https://go.dev/play/p/A-5rPS6eY_b > > - sean > > On Sat, Aug 22, 2026 at 7:39 PM Steven Hartland > <[email protected]> wrote: > > > > Thanks Jason, it already has an Error method but I guess the linter > isn’t checking properly and is missing the embedded error is providing that. > > > > It a nice workaround though 🙂 > > > > Regards > > Steve > > > > On Sat, 22 Aug 2026 at 19:29, Jason Phillips < > [email protected]> wrote: > >> > >> > I even tried with a custom Is function defined, go vet check still > fails. > >> It seems to be the Error function that's significant to the linter here. > >> > >> The linter is happy once your error type implements the error interface. > >> > >> Working example: https://go.dev/play/p/PzjXq1tfgLL > >> > >> On Friday, August 21, 2026 at 6:42:59 AM UTC-4 Steven Hartland wrote: > >>> > >>> Workaround is to run go test with -vet=off > >>> > >>> On Fri, 21 Aug 2026 at 10:10, Steven Hartland <[email protected]> > wrote: > >>>> > >>>> Go 1.27 made stdversion checks run by default when running go test as > well as an extra check for errors.Is compatibility. This checks for > non-pointer types which appears to break compatibility with existing code, > you can see this here > >>>> https://go.dev/play/p/2nXq9OWS-rf?v=goprev > >>>> > >>>> Under go 1.26 the errors.Is works as expected but under 1.27 you get > a compile failure. > >>>> > >>>> If I remove the & so it operates on HTTPError and not *HTTPError as I > believe is suggested by the vet check two of the tests fail as HTTPError is > not comparable. > >>>> > >>>> I even tried with a custom Is function defined, go vet check still > fails. > >>>> > >>>> Am I missing something, or is this a significant compatibility > breakage introduced by 1.27? > >>>> > >>>> With & under 1.27 > >>>> > >>>> # [play] > >>>> ./prog_test.go:27:44: %w wants operand of error type HTTPError, not > pointer type *HTTPError (defeats errors.Is) > >>>> > >>>> Go build failed. > >>>> > >>>> > >>>> Without & on 1.27 > >>>> > >>>> === RUN TestErrorsIs > >>>> === RUN TestErrorsIs/wrapped-eof > >>>> === RUN TestErrorsIs/wrapped-sentinel > >>>> prog_test.go:37: wrapped: &fmt.wrapError{msg:"wrapped eof error: > EOF", err:main.HTTPError{error:(*errors.errorString)(0x86ae60), > StatusCode:404, Details:[]interface {}{"some extra info"}}} is not sentinel > >>>> === RUN TestErrorsIs/direct-sentinel > >>>> prog_test.go:42: sentinel: &fmt.wrapError{msg:"wrapped eof error: > EOF", err:main.HTTPError{error:(*errors.errorString)(0x86ae60), > StatusCode:404, Details:[]interface {}{"some extra info"}}} is not sentinel > >>>> --- FAIL: TestErrorsIs (0.00s) > >>>> --- PASS: TestErrorsIs/wrapped-eof (0.00s) > >>>> --- FAIL: TestErrorsIs/wrapped-sentinel (0.00s) > >>>> --- FAIL: TestErrorsIs/direct-sentinel (0.00s) > >>>> FAIL > >>>> > >>>> Program exited. > >>>> > >>>> > >>>> With & under 1.26 > >>>> > >>>> === RUN TestErrorsIs > >>>> === RUN TestErrorsIs/wrapped-eof > >>>> === RUN TestErrorsIs/wrapped-sentinel > >>>> === RUN TestErrorsIs/direct-sentinel > >>>> --- PASS: TestErrorsIs (0.00s) > >>>> --- PASS: TestErrorsIs/wrapped-eof (0.00s) > >>>> --- PASS: TestErrorsIs/wrapped-sentinel (0.00s) > >>>> --- PASS: TestErrorsIs/direct-sentinel (0.00s) > >>>> PASS > >> > >> -- > >> 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 [email protected]. > >> To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/b7b31927-f85d-4008-b206-f92e4f6e8c70n%40googlegroups.com > . > > > > -- > > 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 [email protected]. > > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/CAA38peZ6%2B4qY5jEdeNuk_%2Bre3q45P6pfV_kzft5oADYdD%3DB-QQ%40mail.gmail.com > . > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAA38peZBgaT5YJvWpsmn9a5e2OASk8O%3DmhOshER1Ep%3D%3DfwXPbg%40mail.gmail.com.
