5 ms·

Just in support of your position, the Google Style Guide says the following: > If a function returns an error, callers must treat all non-error return values a

Just in support of your position, the Google Style Guide says the following: > If a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented otherwise It is absolutely not idiomatic to give any meaning to non-error values under error conditions in the usual case. That is extremely unusual and would be generally confusing. https://google.github.io/styleguide/go/decisions#returning-errors https://google.github.io/styleguide/go/decisions#returning-e...

randomdata 3y ago
> It is absolutely not idiomatic to give any meaning to non-error values under error conditions in the usual case. Based on what? We have come to see that it is beneficial to make zero values useful. In fact, Go Proverbs even says so. Likewise, we have learned it is useful to return the zero value when you have an error. Most commonly, this means returning nil, which is packed full of all kinds of useful information. Therefore, the T value can be expected to useful if the code is idiomatic. I'd love to see some real-world code you think is idiomatic, but doesn't return a useful T value when there is an error. > If a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented otherwise This is not at odds with that. This merely warns that not all code you may call will be idiomatic. In fact, if I recall correctly, doesn't os.Open (maybe os.Create) return an invalid file handle in some error cases? The standard library is old and what helped us eventually see what is idiomatic. It is decidedly not idiomatic for the most part. If you rely on a function being written idiomatically, then you are going to run into trouble, as that is not a guarantee (unless the documentation provides such a guarantee). But in the case of this Either wrapper, it explicitly states it is for use with idiomatic code, not any old code you can throw at it.
- awused 3y ago
  >Based on what? ... In fact, Go Proverbs even says so. And the Go style guide says otherwise: if err is non-nil, you shouldn't even check the other return values. The Go proverbs are just words, it doesn't make them true or even good ideas. When Go proverbs don't agree with how Go code is written, including idiomatic Go code, reality wins over a bad theory. The Go style guide happens to better match real code written by real people, even the people directly responsible for the proverbs. >I'd love to see some real-world code you think is idiomatic To be fair, I have been talking about the Go programming language and idiomatic code written in that language. You seem to have a different idea of "Idiomatic Go" from everyone else's. Most of the stdlib, including the newest additions, is idiomatic as judged by other people but evidently not by you.
  - randomdata 3y ago
    > if err is non-nil, you shouldn't even check the other return values. Yes, it says you cannot trust functions, unless documented, to be idiomatic. Which is reasonable as not all code is idiomatic. The language goes to no lengths to enforce how the code is written in this regard (obviously). But we are talking about code that is known to be idiomatic. > Most of the stdlib, including the newest additions, is idiomatic as judged by other people but evidently not by you. 1. I don't see how it could be. What is idiomatic emerges from writing code and seeing what works and what doesn't. Most of the stdlib was written in the early days before anyone understood what works best. And, thanks to the go1 guarantee, modifying it now is out of the question. 2. If you believe that the stdlib is idiomatic, then you have to accept that returning an int (-1) to represent an error is idiomatic. The standard library is full of that. Which violates the premise of FP-Go that (T, error) is idiomatic. That is not my claim, that is theirs.
    - awused 3y ago
      >Yes, it says you cannot trust functions, unless documented, to be idiomatic. That is not what it says, in fact, it almost says the opposite. It is idiomatic Go to never return useful values if error is non-nil unless explicitly documented. It never affirms your particular, personal, definition of what "Idiomatic Go" is and directly contradicts it. >If you believe that the stdlib is idiomatic I believe most of the stdlib is idiomatic Go, especially the newer stuff. Your excuse earlier was that the older stuff in the stdlib isn't idiomatic but the newer stuff is. But the newer stuff doesn't match your personal standards for being idiomatic either. I would challenge you to point to a large body of code that actually matches your definition of idiomatic, I do not think it exists.
      - randomdata 3y ago
        > It is idiomatic Go to never return useful values if error is non-nil unless explicitly documented. No, it is very much written from a consumer perspective. There is known, non-idiomatic, code where relying on T in its error state is problematic, so the guidance is reasonable and logical. But we're talking about this from the producer perspective. These do not challenge each other and can exist in harmony. > believe most of the stdlib is idiomatic Go, especially the newer stuff. I wholeheartedly agree, at least with respect to the newer stuff, and have already said as such. Now this is where, in that newer work which is idiomatic, you point to a good example of where you can find meaningless return values when there is an error. Clearly the vast majority of the standard library, especially in the newer stuff, does return meaningful values upon error, so we need to identify those which buck the trend if we want to hold it as a counterexample of this being an idiomatic practice.

randomdata 3y ago

> It is absolutely not idiomatic to give any meaning to non-error values under error conditions in the usual case. Based on what? We have come to see that it is beneficial to make zero values useful. In fact, Go Proverbs even says so. Likewise, we have learned it is useful to return the zero value when you have an error. Most commonly, this means returning nil, which is packed full of all kinds of useful information. Therefore, the T value can be expected to useful if the code is idiomatic. I'd love to see some real-world code you think is idiomatic, but doesn't return a useful T value when there is an error. > If a function returns an error, callers must treat all non-error return values as unspecified unless explicitly documented otherwise This is not at odds with that. This merely warns that not all code you may call will be idiomatic. In fact, if I recall correctly, doesn't os.Open (maybe os.Create) return an invalid file handle in some error cases? The standard library is old and what helped us eventually see what is idiomatic. It is decidedly not idiomatic for the most part. If you rely on a function being written idiomatically, then you are going to run into trouble, as that is not a guarantee (unless the documentation provides such a guarantee). But in the case of this Either wrapper, it explicitly states it is for use with idiomatic code, not any old code you can throw at it.

awused 3y ago
>Based on what? ... In fact, Go Proverbs even says so. And the Go style guide says otherwise: if err is non-nil, you shouldn't even check the other return values. The Go proverbs are just words, it doesn't make them true or even good ideas. When Go proverbs don't agree with how Go code is written, including idiomatic Go code, reality wins over a bad theory. The Go style guide happens to better match real code written by real people, even the people directly responsible for the proverbs. >I'd love to see some real-world code you think is idiomatic To be fair, I have been talking about the Go programming language and idiomatic code written in that language. You seem to have a different idea of "Idiomatic Go" from everyone else's. Most of the stdlib, including the newest additions, is idiomatic as judged by other people but evidently not by you.
- randomdata 3y ago
  > if err is non-nil, you shouldn't even check the other return values. Yes, it says you cannot trust functions, unless documented, to be idiomatic. Which is reasonable as not all code is idiomatic. The language goes to no lengths to enforce how the code is written in this regard (obviously). But we are talking about code that is known to be idiomatic. > Most of the stdlib, including the newest additions, is idiomatic as judged by other people but evidently not by you. 1. I don't see how it could be. What is idiomatic emerges from writing code and seeing what works and what doesn't. Most of the stdlib was written in the early days before anyone understood what works best. And, thanks to the go1 guarantee, modifying it now is out of the question. 2. If you believe that the stdlib is idiomatic, then you have to accept that returning an int (-1) to represent an error is idiomatic. The standard library is full of that. Which violates the premise of FP-Go that (T, error) is idiomatic. That is not my claim, that is theirs.
  - awused 3y ago
    >Yes, it says you cannot trust functions, unless documented, to be idiomatic. That is not what it says, in fact, it almost says the opposite. It is idiomatic Go to never return useful values if error is non-nil unless explicitly documented. It never affirms your particular, personal, definition of what "Idiomatic Go" is and directly contradicts it. >If you believe that the stdlib is idiomatic I believe most of the stdlib is idiomatic Go, especially the newer stuff. Your excuse earlier was that the older stuff in the stdlib isn't idiomatic but the newer stuff is. But the newer stuff doesn't match your personal standards for being idiomatic either. I would challenge you to point to a large body of code that actually matches your definition of idiomatic, I do not think it exists.
    - randomdata 3y ago
      > It is idiomatic Go to never return useful values if error is non-nil unless explicitly documented. No, it is very much written from a consumer perspective. There is known, non-idiomatic, code where relying on T in its error state is problematic, so the guidance is reasonable and logical. But we're talking about this from the producer perspective. These do not challenge each other and can exist in harmony. > believe most of the stdlib is idiomatic Go, especially the newer stuff. I wholeheartedly agree, at least with respect to the newer stuff, and have already said as such. Now this is where, in that newer work which is idiomatic, you point to a good example of where you can find meaningless return values when there is an error. Clearly the vast majority of the standard library, especially in the newer stuff, does return meaningful values upon error, so we need to identify those which buck the trend if we want to hold it as a counterexample of this being an idiomatic practice.