Go does not have operator overloading, and numeric operators must have identical types. So if you have `var x int = 5` and `var t time.Duration = 2500 * time.Millisecond`, you have to `time.Duration(x) * t` or `time.Duration(x * int(t))`.

It's slightly better than languages with no operator overloading nor newtypes at all (well, actually a lot better given other things you can use newtypes for) but without operator overloading using it just for units, with no other API machinery, is usually a bad idea.

Two options:

1. Don't type units like that.

2. Allow the * operator to multiply a time-unitful value with an untimed scalar and disallow using it with two time-unitful values.

Presumably the requirement that * operands are the same is arbitrarily modifiable and go developers have control over what types operators take.

1. Uh, ok. Might as well throw out the whole thread then?

2. A "time unit" is not a special type of value. You can construct arbitrary types of integers, and it is common to do so. `*` has no clue what a time is, just that it's "not an int" (for example).

The commenter you're replying to expressed it confusingly. The point is that in Go, 5 * time.Milliseconds(2500) is a type error, and instead you need to do time.Nanoseconds(5) * time.Milliseconds(2500).

`5 * time.Milliseconds(2500)` is not a type error, though `int(5) * time.Milliseconds(2500)` is.

(This is especially relevant because you really mean `5 * (2500 * time.Millisecond)` vs. int(5) * (2500 * time.Millisecond)`, as there is no `time.Milliseconds` function.)

Thanks, I don't remember exactly how it worked. It doesn't take away from the stupidity.