That is a *very* good point. It still seems more obvious that one would check for error instead of pointer to error. If we don't want to do this as part of errors.As (or cannot) it might make sense for golangci-lint. I'm seeing that plain errors is a quite popular pattern?
On Thursday, September 22, 2022 at 5:29:52 PM UTC+2 Tamás Gulácsi wrote: > plain struct error is brittle in other ways, too: you can shoot yourself > on foot with "err != nil" check. > So: error should be a pointer type. > > cpu...@gmail.com a következőt írta (2022. szeptember 21., szerda, > 21:26:31 UTC+2): > >> Consider https://go.dev/play/p/jgPMwLRRsqe: >> >> errors.As(err, <plain type>) will not match if error is of pointer type. >> As a result, a library consumer needs to understand if a library returns >> Error or *Error. However, that is not part of the API spec as both returns >> would satisfy error if Error() is implemented on the plain type. >> >> A potential workaround would be using Error.As(any) to match >> plain/pointer type as part of the library. However, it seems >> counterintuitive having to do so if errors.As() doesn't by default. >> >> Would it make sense (and I would like to propose) to expand errors.As() >> to match plain receiver types even when err is a pointer to the same >> underlying plain type. >> >> What do you think? >> >> Cheers, >> Andi >> > -- 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 on the web visit https://groups.google.com/d/msgid/golang-nuts/447df3bc-1b1f-4bcb-82e3-cc918afe43dbn%40googlegroups.com.
