With `type Seconds float64` and `type Millis float64`, why does `Millis(s)` compile, and how do you stop unit mix-ups?

## Why the conversion compiles Go's two relations do different jobs, and the gap between them is where this bug lives. **Assignability** requires identical underlying types *and* that at least one of the two types is not a named type. `Seconds` and `Millis` are both defined types, therefore both named, so `var m Millis = s` is rejected and so is passing a `Seconds` to a parameter of type `Millis`. Good. **Convertibility** is wider. `T(x)` is permitted when `x` is assignable to `T`, **or** when the two types have identical underlying types — with no named/unnamed condition at all. Both are `float64` underneath, so `Millis(s)` is legal. And the conversion between two types with the same underlying type is a *reinterpretation*: no scaling, no rounding, no check, no run-time cost. The number 30 stays 30 and only the label changes. So a defined type gives you a barrier against **accidental** mixing and no barrier whatsoever against a **written** conversion. That distinction is the whole answer, and it is why `type Seconds float64` is a review aid rather than a safety mechanism. ## Why nothing catches it - The compiler cannot: as far as the type system is concerned the conversion is exactly what it was asked for. - `go vet` has no analyzer for unit semantics; there is nothing to enable. - There is no run-time signal. The value is plausible, the program does not panic, and a 30-second timeout that became 30 milliseconds shows up later as retries, flapping health checks or a mysteriously high error rate. - Tests usually miss it, because the test constructs its own value in whichever unit the code under test expects. The conversion is also *attractive* at exactly the wrong moment. Someone deleting a deprecated code path finds a call that no longer compiles because the replacement function takes the other unit, and the fastest way to make the build green is to wrap the argument in the target type. The diff looks like a type fix. It is a semantic change. ## Making the wrong thing hard to write **1. Give the scaling a name, and make it the only public path.** ```go func (s Seconds) Millis() Millis { return Millis(s * 1000) } ``` Now `timeout(s.Millis())` and `timeout(Millis(s))` sit next to each other in review and read completely differently. This is the cheapest change and catches most cases. **2. Keep raw conversions in one package.** Every `Millis(...)` on a value that is not already a plain number should live in the file that defines the types. Elsewhere, call the method. A grep for the conversion syntax then has a small, auditable answer. **3. Prefer `time.Duration` for durations.** It is the standard library's unit type, it carries nanoseconds, and its arithmetic and constants (`30*time.Second`) make the unit visible at the construction site. Two teams inventing `Seconds` and `Millis` in parallel is itself the bug; one shared duration type removes the conversion entirely. **4. Where it genuinely matters, remove convertibility.** Wrap the number: ```go type Millis struct{ v float64 } ``` A struct's identity includes its field names, and an unexported field name is qualified by its declaring package. So from any other package there is no type with an identical underlying type, and `Millis(x)` simply does not compile — the only way in is the constructor you export. The price is that arithmetic now goes through methods and the value stops printing as a bare number. Spend that price on money, on physical units in a control path, and on identifiers that must never cross — not on everything. ## The same trap without numbers It is not a float64 problem. With ```go type UserID string type OrderID string ``` `OrderID(u)` compiles just as silently, and produces a lookup against the wrong table with a well-formed UUID that exists nowhere. The failure is quieter than the duration case because the value looks exactly right in a log line. The same three defences apply, and the struct-wrapper defence is the one that actually holds when the ids are opaque strings that no reviewer can distinguish by eye. ## A related silent conversion worth knowing Conversions between *different* numeric underlying types do not reinterpret — they convert, and they can lose data without a word. `int(f)` on a `float64` truncates toward zero; `int8(300)` on a variable wraps. (A constant is different: `int(3.9)` written literally is a compile error, because the untyped constant is not representable.) In review, treat any numeric conversion on a non-constant value as a place where a comment should explain why the loss is acceptable. ## What to say in an interview Name the asymmetry first — assignability blocks it, convertibility does not, and conversion between identical underlying types is a relabel. Then say what you do about it, in the order of cost: scaling methods, conversions confined to one package, `time.Duration` where it fits, struct wrappers where the incident would be expensive. Finish with the review heuristic: a conversion appearing in a diff whose purpose was to make the build compile is the single highest-yield thing to question.