4 ms·
I'm not sure if type aliasing is for that use case. I think you're more thinking about things like type Celsius int that in theory prevent you from passing
by justinsaccount 9y ago
I'm not sure if type aliasing is for that use case. I think you're more thinking about things like
type Celsius int
that in theory prevent you from passing a bare int and mixing up Celsius/Fahrenheit.
In go this almost works. If you define
type Celsius int
func isBoiling(t Celsius) bool {
return t >= 100
}
then You need to call it by doing something like
t := Celsius(100)
isBoiling(t)
and just
t := 212
isBoiling(t)
will not compile with
cannot use t (type int) as type Celsius in argument to isBoiling
But unfortunately you can get away with
isBoiling(212)
However, If you just used a type alias then you'd be able to do either.
- thomas11 9y agoRight. You could always define a new type with an existing underlying type, like Celsius with the underlying type int in your example. See the spec here: https://golang.org/ref/spec#Types https://golang.org/ref/spec#Types This would define a new, non-interchangeable type, even though it's just an int behind the scenes. The new type alias on the other hand define a new name for an existing type; you still have just one type. In the user ID example above that's not what you want, it would allow using an int where a UserID is required.
- frou_dh 9y agoAs I understand it, there have been a couple of compiler-blessed aliases for a long time (byte -> uint8 and rune -> int32), making this a similar thing but now at user level.
- tracked24x7 9y ago> But unfortunately ... It is not due to some unkind turn of fortune that the Go type system drops the ball here and there. > However, If you just used a type alias then you'd be able to do either. The important distinction between a type and an alias is that you can define methods for a type and you can not do the same for an alias.
- hardwaresofton 9y agoThanks for the clarification! You're absolutely right -- Go's regular types would have actually helped with that. I don't know that I would build the same kind of type machinery though (I might only use the alias, not the actual type), since a call like isBoiling(212) would fall apart. In particular, I think the type aliasing will make function signatures a lot clearer -- if I to write a `Celsius` type class, I would likely just make a small, hopefully simple `Temperature` type. Unfortunately last time I wrote any Go code, I wasn't anywhere near that careful/purposeful with the types (I mostly left things as `int`s, etc)
- ithkuil 9y agoGo constants are untyped, which means you can pass a number as argument to a function that takes a type whose underlying type is an integer (e.g. time.Duration) without having to explicitly mention the type. That's how time.Sleep(5 * time.Minute) works
- shurcooL 9y ago> But unfortunately ... You can't get away with: isBoiling(Fahrenheight(212)) cannot use 212 (type Fahrenheight) as type Celsius in argument to isBoiling