I don't believe this is contradictory. TL;DR: `error` is a (very) special case, part of the language specification itself.
Long-form (my take): The guidance in CodeReviewComments relate to interface types and any implementation defined by a project. The guidance in faq#nil_error relates to correct/safe use of the built-in `error` type. Yes, the `error` type is, strictly speaking, an interface, but it is not one that a project has to define (which is what the code review comments discussion relates to). Accordingly, the discussion/advice relating to producer vs consumer declaration of project-defined interfaces and any relationship between returned value types and any interface declaration that might exist to express a contract with any concrete type is irrelevant to the use of `error` values (and similarly the `any` interface). On Thursday 26 September 2024 at 09:03:48 UTC+12 Mike Graf wrote: > Sorry to revive this, but I'd like to add to conversation (without > weighing in on correctness of the nil check) that it appears the CodeReview > comments on interfaces ( https://go.dev/wiki/CodeReviewComments#interfaces > ) and the FAQ nil error https://go.dev/doc/faq#nil_error give mutually > exclusive guidance. > > > > On Wednesday, September 2, 2020 at 6:09:51 PM UTC-6 Ian Lance Taylor wrote: > >> On Wed, Sep 2, 2020 at 3:45 AM targe...@gmail.com <targe...@gmail.com> >> wrote: >> > >> > > Other people have said this too, but I want to emphasize that there >> > are not 4 potential states of an interface value. There are 2 >> > potential states: 1) interface does not hold any value, and is == nil; >> > 2) interface holds a value, and is != nil. >> > >> > Indeed, there are 2 states of interface observable from outside. >> Although one of these observable states gets expressed through 2 states >> invisible to outer world. Which isn't a problem on its own. >> > >> > > When you start talking about an interface as a fat pointer you are >> > talking about how those 2 states are implemented. There are other >> > possible implementations >> > >> > Yes. And that's not an issue on its own. The issue is, such >> implementation detail kind of "leaks" sometimes and bites you when you >> don't expect. And it does so because the way it gets constructed omits one >> specific detail of conversion from pointer to interface. >> >> I don't think that is correct. The implementation detail never leaks. >> An interface always either holds a valid value (is != nil) or does not >> hold a valid value (is == nil). >> >> I believe the confusion is due to the overloading of "nil". It means >> both an invalid interface and an invalid pointer, but you are >> permitted to store an invalid pointer in a valid interface. >> >> Ian >> > -- 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/8ac89551-60d8-4212-862c-ad22f9f60f97n%40googlegroups.com.
