As a general rule, convert incoming input (user or otherwise) to the correct type as quickly as possible, and convert it to the outgoing type as late as possible. When programming in this style, for you to reach the point in the code where the Set call is being made and for you to still have 4 &quot;int&quot;s almost certainly means you should have converted them earlier. Generally you&#x27;ve got a validation phase somewhere, which is where this should be converted, which means that your &quot;Width&quot; isn&#x27;t just &quot;what happended to be in the input&quot; but is a &quot;validated Width&quot; as well. Since it floats on the validation code it&#x27;s often not even 1 extra line of code, just another token that I mentally model as sort of &quot;sealing&quot; the fact that this is a good value.<p>This rule goes <i>way</i> beyond &quot;tiny types&quot;; for instance you will drive yourself insane in the web world if you don&#x27;t do this, with double-decodings and double-encodings quite challenging to prevent with any other policy. [1]<p>&quot;Further, it makes Godoc more confusing, since now I have to search around to figure out what each of these custom types is.&quot;<p>Absolutely yes. In any language where this is possible and easy, I do wish the auto-doc systems either automatically, or with some metadata (preferably a label on the type somehow), would make it clear when something is just a one-layer wrapper around a simple type in all the places where it appears in the docs, without having to click through. I consider it worth the cost, but this is definitely an entry on the cost column that is accidental, not essential. This is especially true when the base type is numeric, which means that Go will let you pass in a literal number in the source code, but that is not always your first expectation.<p>[1]: In a statically-typed language you can also play games with having the type label what &quot;layer&quot; of decoding the value is currently in, which works but gets more tedious. This is theoretically possible in a dynamic language, but goes against the grain, since generally people program with just &#x27;strings&#x27; in those languages.