Type identity and underlying types

Canonical guidance

• type A B defines a new named type
• type A = B creates an alias, not a new type
• underlying types matter for conversions, constraints, and some assignability rules

Use when

• debugging type mismatches
• designing wrappers around existing types
• reasoning about generic constraints using ~T

Avoid

• assuming two types are interchangeable because they print similarly
• using new named types when an alias is what migration needs
• reasoning about underlying types when identity already settles the question

Preferred pattern

type UserID string

Anti-pattern

• expecting a newly defined named type to be identical to the original type without explicit conversion

Explanation: This is tempting because the underlying representation is the same, but the language intentionally makes the new type distinct.

Why

• identity and underlying-type rules sit under many conversion, interface, and generics questions