Comment by randomdata
Comment by randomdata 7 days ago
You're still only halfway there, as we discussed earlier.
Go calling convention is that you have to assume T is invalid, unless proven otherwise, because we know there are developers who have no business being developers that will screw you over if not careful. The Go style guide promotes documenting in a function comment that your function does return a valid T so that users don't have to guess about whether or not you are competent.
But the convention on the function authoring side is to always ensure T is valid. Just because others shouldn't be writing code does not mean you need to be among them.
As Go promotes limiting use of third-party packages by convention, as a rule most of the functions you call are going to be your own. So most of the time you can be sure that T is valid, regardless of error state. Yes, sometimes you are forced to rely on the error, as we discussed already in earlier comments. Such is life.
> the convention on the function authoring side is to always ensure T is valid.
I'm not sure where you got this idea from. It's not (in the general case) true. But do as you like, of course.