5 ms·

Type aliasing! type T1 = T2 I'm currently writing a pretty large project in Haskell and am thoroughly enjoying it -- as everyone and their mother says, the

Type aliasing! type T1 = T2 I'm currently writing a pretty large project in Haskell and am thoroughly enjoying it -- as everyone and their mother says, the type system is superb, and even simple aliases like: type UserID = Int Make it so much easier to read and understand functions.

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 ago
  Right. 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 ago
    As 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 ago
  Thanks 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 ago
    Go 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
  - kevhito 9y ago
    You can if func Fahrenheight(f int) Celsius { return Celsius(5*(f-32)/9) }
    - shurcooL 9y ago
      Well, sure, but I meant that in the context of: type ( Celsius float64 Fahrenheit float64 )
scalatohaskell 9y ago
You should Newtype it though. Type aliases aren't substitute for semantics. They are for to simplify naming of complicated types.
- jlouis 9y ago
  In the Go world, they also serve as a way to gradually shift code around. Large code bases tend to have parts which are on transition from an "old" way to a "new" way, and type aliases allows you to maintain a backwards compatible stub type for a newly changed system. This then avoids the patch of 40k lines changed as you can gradually go to different teams and get a checkmark that the changes you made to the teams code is still going to work as expected. This is usually better coordination-wise than a 40k line patch everyone has to sign off on.

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 ago
Right. 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 ago
  As 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 ago
Thanks 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 ago
  Go 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
- kevhito 9y ago
  You can if func Fahrenheight(f int) Celsius { return Celsius(5*(f-32)/9) }
  - shurcooL 9y ago
    Well, sure, but I meant that in the context of: type ( Celsius float64 Fahrenheit float64 )

scalatohaskell 9y ago

You should Newtype it though. Type aliases aren't substitute for semantics. They are for to simplify naming of complicated types.

jlouis 9y ago
In the Go world, they also serve as a way to gradually shift code around. Large code bases tend to have parts which are on transition from an "old" way to a "new" way, and type aliases allows you to maintain a backwards compatible stub type for a newly changed system. This then avoids the patch of 40k lines changed as you can gradually go to different teams and get a checkmark that the changes you made to the teams code is still going to work as expected. This is usually better coordination-wise than a 40k line patch everyone has to sign off on.