Go 1.9 and type aliases

[Robert Griesemer]

The master branch's compiler and go/* libraries now support type aliases ( https://github.com/golang/proposal/blob/master/design/18130-type-alias.md ). The exact Go spec wording is still being worked on, but in essence there are now two forms of type declarations:

1) "type" identifier       Type .

2) "type" identifier "=" Type .

Both forms bind a name to a type. In 1), as before, the declaration first creates a new type and the identifier denotes that newly created type. In 2), the identifier simply denotes the type on the right.

For example it's now possible to write

type intList = []int

type localT = imported.T

and both intList and []int denote identical types, and so do localT and imported.T.

We made a point of getting this code working at the start of the 1.9 cycle so that we have enough time to get familiar with it and to iron out issues early.

I am personally very confident that we now have the correct language change, but please keep in mind that there's still a (remote) chance that we may have to make adjustments due to unforeseen issues. In other words, don't bet your company's code on type aliases quite yet. Also, as much as I'd like to make use of them in the Go compiler, we can't as long as we need an older version to build it. Assuming all goes as planned, type aliases will be a committed language feature for 1.9.

Please give it a try and file issues if you find any. Thanks!

- gri, for the Go Team

[zhaox...@gmail.com]

So for:

type intList = []int

Is intList named type or unnamed type?

[Robert Griesemer]

intList will act as an "unnamed type" because it is simply a name for []int and denotes exactly []int (they are identical). Thus, using the current, unchanged terminology, it is an unnamed type.

Which admittedly is confusing, and this is why we are working on an appropriate change of the spec terminology. Stay tuned!

- gri

[Matthew Dempsky]

On Feb 1, 2017 5:40 PM, <zhaox...@gmail.com> wrote:

So for:

type intList = []int

Is intList named type or unnamed type?

The name intList is bound to the unnamed type []int.

At least that's how I'd currently describe it. Like Robert mentioned, we're still discussing the precise spec wording.

[Dave Cheney]

This makes me so mad.

Now I can no longer teach Go as named and unnamed types. Instead I
have to say "oh, unless it's an alias, in which case you have to
remember that it's actually an unnamed type, even when you import to
from another package."

package main

import (
"fmt"
"q"
)

func main() {
var a q.A
var b q.B // i'm a named unnamed type !!!

fmt.Printf("%T\t%T\n", a, b)
}
deadwood(~/src) % go run main.go
q.A []int

--
You received this message because you are subscribed to the Google
Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Griesemer]

There's also a different way to look at this:

Now, a type declaration using '=' has finally become like any other declaration: It simply binds a name to a type, and that name denotes exactly that type.

In fact, our prior "named type" declaration was always doing more, we just never talked about it a whole lot (though the section on type declarations is pretty explicit about it): It creates a new type _first_, before the identifier is bound to it (this is somewhat similar to a variable declaration, which also does two things: it reserves space for a variable, i.e., it "creates" the variable, and then binds the name to that variable).

It just so happened that the language doesn't have any specific operator to create such a new type besides using a type declaration; and thus each such newly created type had a name and vice versa. We didn't bother coming up with an explicit term for that type, and because of the 1:1 relationship with names, we called them named types.

Now, a named type is simply a type with a name. And that is just fine. It actually simplifies a lot of things.

We just need a way to refer to these newly created types. We've been alluding to this for a while now; and the design doc mentions this as well. As an aside, other languages do exactly the same. Modula-3 has the notion of a "branded" type, and in C++ the equivalent is a named struct or class. In all these cases, the type name is just a name that happens to point to a type that's been created on the spot and that's different from any other type.

So yes, there's a terminology change. And yes, it's annoying for long-time Go users. But it's also the long-time Go users who will get over this very quickly. And the new Go users (of which there are going to be way way more then existing Go users, assuming Go use continues to grow), they won't care because they just get used to the new terminology.

In summary: Let's agree on a spec change and then let's just get over it.

- gri

an email to golang-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.

[Russ Cox]

On Wed, Feb 1, 2017 at 10:05 PM, Dave Cheney <da...@cheney.net> wrote:

This makes me so mad.

Now I can no longer teach Go as named and unnamed types. Instead I
have to say "oh, unless it's an alias, in which case you have to
remember that it's actually an unnamed type, even when you import to
from another package."

Robert already said (in the message you quoted) "Which admittedly is confusing, and this is why we are working on an appropriate change of the spec terminology. Stay tuned!". And Matthew said "Like Robert mentioned, we're still discussing the precise spec wording." And the design doc itself says "Note: It’s possible that due to aliases, the spec term “named type” should be clarified or reworded in some way, or a new term should replace it."

If you'd like to take part in a constructive discussion, great. Rants belong somewhere else.

Thanks.

Russ

[zhaox...@gmail.com]

Yes, it might be better to rephrase "named type" and "unnamed type" to some other terms, otherwise it will be really confusing.

[Robert Griesemer]

The latest spec has been adjusted accordingly. If you read the sections on

https://tip.golang.org/ref/spec#Types

and 

https://tip.golang.org/ref/spec#Type_declarations

it's hopefully not that confusing anymore.

For a start, what we used to call a "named type" before is now called a "defined type". They both mean the same concept, we just use different terminology now (because there's no more than just one kind of named type).

- gri

On Wed, Feb 8, 2017 at 6:51 PM, <dfsg...@mail.com> wrote:

Right now it is a bit confusing for those not in the circle-jerk.

[dfsg...@mail.com]

proto it, spec it, beta it, release it, then if necessary rollback it. follow your own guidelines.

an email to golang-dev+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

[dfsg...@mail.com]

I'm not sure I see the rant. I see a person stating his discontent with a feature that is being aggressively pushed on to the community in a half-assed manner. prototype it, spec it, beta it, then push it in a release. Follow your own set of guidelines.

[dfsg...@mail.com]

[Ian Lance Taylor]

On Wed, Feb 8, 2017 at 6:48 PM, <dfsg...@mail.com> wrote:
> I'm not sure I see the rant. I see a person stating his discontent with a
> feature that is being aggressively pushed on to the community in a
> half-assed manner. prototype it, spec it, beta it, then push it in a
> release. Follow your own set of guidelines.

I think you are describing exactly what happened. I'm not sure what
you are objecting to.

Ian

[Robert Griesemer]

This has been spec'ed, is now in beta, and hopefully will make it into the 1.9 release which is half a year out. There has been fairly strong support for this revised form of alias declarations, and there's nothing aggressive about the current roll-out, which is exactly so that people can experiment with it.

The only thing aggressive and half-assed at this point is the manner in which you are conducting yourself in this conversation. Please familiarize yourself with https://golang.org/conduct. If you disagree, there's plenty of opportunity to rant elsewhere. Thanks.

- gri

On Wed, Feb 8, 2017 at 6:48 PM, <dfsg...@mail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "golang-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.

[quas...@gmail.com]

Is "type aliases as lighweight type hints" - misuse?

Example:
Given a library interface type `js.Object` which represents "any JavaScript object" we want
to express `js.Number`, but that library provides support for `js.Object` type only.
We introduce a `type Number = js.Object` and declare "known to be numbers"
types as `Number`. This way, `js.Number` can be passed as `js.Object`.

Not type safe (and abstraction is leaky), but at least APIs are more precise.

[Robert Griesemer]

I don't know your library interface in detail, but:

A type alias is simply an alternative name for an existing type, nothing more, nothing less.

If you write

type Number = js.Object

your Number type is the js.Object type - they are one and the same type. I don't know that this is the right approach for your library.

I suspect what you want is for js.Object to be some sort of interface, and Number an concrete implementation of that interface.

Please direct further questions to the community. Thanks.

- gri