>No, it is very much written from a consumer perspective. We're talking about from the producer perspective.
This is just a lie. It's written about Go and doesn't split its perspectives, the producer should only ever return meaningful non-error values with an error if explicitly documented, and the consumer should only ever expect those when documented.
>you point to a good example of where you can find un-meaningful return values when there is an error.
Okay, skimming the release notes for 1.21. The slog package, brand new in 1.21, contains a MarshalText method (and others, but this is the first I noticed). It returns ([]bytes, err) and it is not documented to be idiomatic as per your personal definition. Therefore, by your interpretation of the style guide and your own personal standards, it is not idiomatic. What's more, a nil/empty slice is potentially valid output from marshaling something, so the slice is entirely useless and must be ignored if err is non-nil. It is not valid to try to "derive meaning" (your terminology) from the slice being nil or not, so it is well and truly useless if err isn't nil.
Moreover, I'll assert that if Either existed in the stdlib, it would return Either[bytes[], err] instead of ([]bytes, err), and it is a limitation of Go that they're using (T, error) which does not offer the appropriate semantics.
>Clearly the vast majority of the standard library, especially in the newer stuff, does return meaningful values upon error
> The slog package, brand new in 1.21, contains a MarshalText method
At quick glance, I found three MarshalText implementations in the slog package. Which implementation are you referring to specifically?
And, for what it is worth, none of them return useless values on error, so where do I find the fourth which does?
> This, too, is simply a lie.
Let's hope. I love nothing more than being wrong. That means I get to learn something new! But I haven't found it yet, which is sorrily disappointing. Looking forward to you clarifying the above so we can put this to rest.
You are now claiming that they are useful when you must discard them as useless when the error is non-nil. At least with you being caught in such a plain and clear lie I can be done with this.
>I love nothing more than being wrong.
That's odd, because you've contorted yourself into defending absurd positions based on personal definitions no one else shares, including the Go authors, just to avoid admitting you were wrong. The same Go authors responsible for both the proverbs, which you quote as gospel, and the style guide, which you claim doesn't apply when it's inconvenient because it directly contradicts your claims in plain english.
> You are now claiming that they are useful when you must discard them as useless when the error is non-nil.
Is it that you've confused implementation with interfaces? I would have to reject the values if received through the TextUnmarshaler interface, which defines MarshalText, as the implementation being called then becomes unknown, and therefore may not be idiomatic. If I was knowingly working with the three concrete types mentioned above then their function is documented.
> That's odd, because you've contorted yourself into defending absurd positions based on personal definitions no one else shares, including the Go authors, just to avoid admitting you were wrong
I mean, all you have to do is show some code which is reasonably considered idiomatic that does not return a useful value when in an error state and I'll be convinced; something you agreed was pertinent and useful when you brought up MarshalText.
The slog package is definitely reasonably considered idiomatic, so you are on the right track. Now you just need to be more specific at to which MarshalText method you are actually referring to. You called attention to it for good reason, no doubt. All we need, as there is more than one, is to know which one you meant specifically. It is a little odd you didn't do that in the first place, but I'm sure it was an accidental omission.
This is just a lie. It's written about Go and doesn't split its perspectives, the producer should only ever return meaningful non-error values with an error if explicitly documented, and the consumer should only ever expect those when documented.
>you point to a good example of where you can find un-meaningful return values when there is an error.
Okay, skimming the release notes for 1.21. The slog package, brand new in 1.21, contains a MarshalText method (and others, but this is the first I noticed). It returns ([]bytes, err) and it is not documented to be idiomatic as per your personal definition. Therefore, by your interpretation of the style guide and your own personal standards, it is not idiomatic. What's more, a nil/empty slice is potentially valid output from marshaling something, so the slice is entirely useless and must be ignored if err is non-nil. It is not valid to try to "derive meaning" (your terminology) from the slice being nil or not, so it is well and truly useless if err isn't nil.
Moreover, I'll assert that if Either existed in the stdlib, it would return Either[bytes[], err] instead of ([]bytes, err), and it is a limitation of Go that they're using (T, error) which does not offer the appropriate semantics.
>Clearly the vast majority of the standard library, especially in the newer stuff, does return meaningful values upon error
This, too, is simply a lie.