[randomdata]

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.

[kiitos]

> 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.