[int_19h]

I don't see what other upsides are there aside from the slightly more convenient syntax, though. In other languages methods also serve as part of encapsulation mechanism, but in Go all visibility is handled on package level. What other upsides do you have in mind?

Don't get me wrong, BTW, I'm not at all a fan of Go overall design and numerous inconsistencies and limitations. But, in this case at least, they have a valid point wrt complexity of the feature (which, to be fair, is largely induced by design of Go's other features, but it is what it is at this point) versus its usefulness. I can only wish for other PL warts of Go to be as minor as this one.

[the_gipsy]

Don't ask me, ask why go does it, all over the stdlib, 3rd party libs, and projects (your project too), and why this fact directly contradicts your interpretation of the doc comment about being "questionable".

I am okay with go doing lots of type complexity tradeoffs for one of the fastest and leanest compilation times out there. I'm not okay with the go creators consistently gaslighting readers into believing that this tradeoff is not happening. In other words, they want to have the cake (speed) and eat it too (my type system is actually good).

I understand that in this day and age, you are forced to do marketing (manipulate the truth) to make a PL popular. But the go project just does it too blatantly for my taste.