Go 1.9 Beta 1 release notes

Re:Go 1.9 Beta 1 release notes by justinsaccount on Wednesday June 14, 2017 @09:41PM (#14557349)

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.

[ Parent | on HN ]

Re:Go 1.9 Beta 1 release notes by thomas11 on Wednesday June 14, 2017 @09:46PM (#14557367)

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

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.

[ Parent | on HN ]

Re:Go 1.9 Beta 1 release notes by frou_dh on Thursday June 15, 2017 @07:39AM (#14559393)

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.

[ Parent | on HN ]

Re:Go 1.9 Beta 1 release notes by tracked24x7 on Thursday June 15, 2017 @12:01AM (#14557858)

> 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.

[ Parent | on HN ]

Re:Go 1.9 Beta 1 release notes by hardwaresofton on Thursday June 15, 2017 @02:21AM (#14558295)

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)

[ Parent | on HN ]

Re:Go 1.9 Beta 1 release notes by ithkuil on Thursday June 15, 2017 @03:22PM (#14563564)

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

[ Parent | on HN ]

Re:Go 1.9 Beta 1 release notes by shurcooL on Thursday June 15, 2017 @04:17AM (#14558700)

> But unfortunately ...

You can't get away with:

    isBoiling(Fahrenheight(212))

    cannot use 212 (type Fahrenheight) as type Celsius in argument to isBoiling

[ Parent | on HN ]

Re:Go 1.9 Beta 1 release notes by kevhito on Thursday June 15, 2017 @10:02AM (#14560443)

You can if

    func Fahrenheight(f int) Celsius {
      return Celsius(5*(f-32)/9)
    }

[ Parent | on HN ]

Re:Go 1.9 Beta 1 release notes by shurcooL on Thursday June 15, 2017 @06:03PM (#14564813)

Well, sure, but I meant that in the context of:

    type (
        Celsius    float64
        Fahrenheit float64
    )

[ Parent | on HN ]