[Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

Evolution Announcements
21

What is your evaluation of the proposal?

I'm ok

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, the current keyword is odd

  * Does this proposal fit well with the feel and direction of Swift?

Not bad, this would be my second choice if I was the only one using swift (the cz

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

N/A

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A bit more than a quick reading of the discussion

Pierre

···

Le 3 janv. 2016 à 07:38, Douglas Gregor <dgregor@apple.com> a écrit :

Hello Swift community,

The review of "Replace `typealias` keyword with `associatedtype` for associated type declarations” begins now and runs through Wednesday, January 6th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

22

I have proposed the elimination of associated types by replacing them with generic arguments and an implementation of generics that allows covariance, see:

  [swift-evolution] Make generics covariant and add generics to protocols <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006367.html&gt; <>

Food for though for another way forward?

PS I agree using typealias for two different concepts is confusing.

···

On 3 Jan 2016, at 5:38 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "Replace `typealias` keyword with `associatedtype` for associated type declarations” begins now and runs through Wednesday, January 6th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

23

+1 from me. It is a solid change that addresses an oddity in the language.

···

On Sun, Jan 3, 2016 at 7:27 AM, plx via swift-evolution < swift-evolution@swift.org> wrote:

I like this.

On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "Replace `typealias` keyword with `associatedtype` for
associated type declarations” begins now and runs through Wednesday,
January 6th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?

It’s a good idea and improves the language.

* Is the problem being addressed significant enough to warrant a change
to Swift?

Yes, the existing situation is comprehensible (if you think like a
language-implementer) but highly non-intuitive and generally sub-optimal
for language users.

* Does this proposal fit well with the feel and direction of Swift?

Yes; conservation-of-reserved-terms is valuable, but giving different
things different names fits the feel much better here.

* If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

To the extent I’m aware of analogous situations in other languages, none
of them actually seem to use distinct keywords, but they also don’t have
the confusing situation Swift has vis-a-vis typealiases with concrete
definitions (in protocols).

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Quick read, plus having been bit by issues the proposal addresses numerous
times.

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Cheers,
Doug Gregor
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

24

I have one concern with `associated` vs `associatedtype`, which is that it people might, in the interest of clarity, start naming things using a conventions like

`associated PayloadType`,

when I think it would be better to have

`associatedtype Payload`

because it leaves less room for interpretation about how to name things idiomatically.

But I still haven’t completely decided between `type` and `associatedtype`, and I plan to respond to this thread separately with my thoughts on that.

Matt

···

On Jan 3, 2016, at 10:10, Alex Migicovsky via swift-evolution <swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?

I think the proposal is great. The only thing I’d prefer is to use `associated` over `associatedtype`.

`associated` has always felt better to me over `associatedtype`. It was mentioned in one of the original proposals as the keyword that was initially most well received as well—I think this is because it just feels right, which is a good indicator even though it doesn’t seem scientific :-)

One downside mentioned is that `associated` is more vague than `associatedtype`, but there’s a reason why we don’t have `protocoltype`, `classtype`, etc as keywords over `protocol` and `class`. I think the convention of having associated type names start with an uppercase letter makes it clear that what follows `associated` is a type (or will be a concrete type).

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes, I’ve seen many developers be confused by the difference between defining a typealias inside a protocol declaration vs outside.

* Does this proposal fit well with the feel and direction of Swift?

Yes.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve been paying attention to the thread and have thought about why I like `associated` over `associatedtype` since the start of the thread.

- Alex
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

25

Hi Drew,

Thanks for the review, just a quick remark:

“Real” type aliases are already forbidden inside protocols, so this proposal wouldn’t change that.
(According to the grammar, a protocol body can only contain: property, method, initializer, subscript, or associated type member declarations)

In your example, secondstype and usecstype were associated types with initial values. To convince yourself, try to create this function
func bar(_: Foo) { }
and you should see the "can only be used as a generic constraint because it has Self or associated type requirements” error.

I initially wanted to allow type aliases inside protocols, and I was told type aliases weren’t requirements, so they shouldn’t be defined inside protocols, which makes sense to me.

We might want to reconsider this, but I think it is outside the scope of this proposal.

Loïc

···

On Jan 3, 2016, at 11:46 AM, Drew Crawford via swift-evolution <swift-evolution@swift.org> wrote:

  * What is your evaluation of the proposal?

+1

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. A typealias in a protocol and a typealias anywhere else are 2 very different things.

* One is almost a preprocessor macro
* The other basically defines the protocol as a generic type, which has a lot of strange follow-on consequences

There are plenty of questions online related to this confusion.

In addition the change is trivial and code could be transitioned automatically.

  * Does this proposal fit well with the feel and direction of Swift?

The choice of keyword "associatedtype" is already used in a common compiler error message:

protocol 'Printable' can only be used as a generic constraint because it has Self or associated type requirements

Using "associatedtype" here is consistent with that error message and makes it more understandable for new users.

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I am an occasional user of Rust; Rust uses the same keyword ("type") in both of these cases. IMO that choice is suffers from the same problems in Rust that it does here.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

One "potential" problem with this proposal is that it technically forbids the use of a "real" typealias in a protocol e.g.

protocol Foo {
    typealias F = Int
}

is now illegal.

To evaluate the severity of this problem I checked a private codebase with 47 usages of typealias. One usage of the 47 would be illegal:

protocol Foo {
    if arch(x86_64) || arch(arm64)
                typealias secondstype = Int64
                typealias usecstype = Int64
          #else
                typealias secondstype = __darwin_time_t
                typealias usecstype = __darwin_suseconds_t
           #endif
  func setTimeout(s: secondstype, u: usecstype) throws
}

I refactored this to move the typealiases to top level. That is not ideal, but I think it is outweighed by the advantages of this proposal.

While auditing this codebase for illegal typealiases I did find a comment that was quite confused about the difference between typealias and associatedtype. So that convinces me even more about the importance of this proposal.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

26

I’m confused, what are you saying? No decision has been made here, I’m not aware of any “secrecy” issue.

-Chris

···

On Jan 3, 2016, at 10:55 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

I'm not opposing the proposal, but I wonder why there has been such a big discussion (and a poll whose results have neither been revealed completely nor affected the choice of the keyword)…

Swift has proven it can thrive in secrecy, so I don't think the whole open community is a necessity — but as it is now, we should hold transparency in high esteem and not start faking democracy.

27

Why has there been such a big discussion? I suspect because this is an obvious win. There's less discussion of "should there be this change" and more of "how should this be changed". The relative lightweight nature of the latter inspires lots of input. When a topic gets more technical in nature, those who are heavily invested, with expertise in building compilers and with specialized knowledge of other languages, focus the discussion.

Turns out in the end that there was an underlying "term of art" (or however that is put) along with the descriptions in the book, so there never was going to probably be anything deeper than "associatedType", "associatedtype" or "associated", in my opinion.

Why secrecy? There is none. I was asked to run a poll. I ran a poll using the best information I had at the moment. I don't have money to spend on SurveyMonkey so it cut off at 100 replies. You can't see the extra replies. I can't see the extra replies. Even playing field.

-- Erica, who had no ulterior motives

···

On Jan 3, 2016, at 2:31 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 3, 2016, at 10:55 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

I'm not opposing the proposal, but I wonder why there has been such a big discussion (and a poll whose results have neither been revealed completely nor affected the choice of the keyword)…

Swift has proven it can thrive in secrecy, so I don't think the whole open community is a necessity — but as it is now, we should hold transparency in high esteem and not start faking democracy.

I’m confused, what are you saying? No decision has been made here, I’m not aware of any “secrecy” issue.

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

28

I'd argue that there's been such a big discussion because it's basically a bikeshed. This is an easy topic for everyone to understand so there's low barrier to entry, and it basically boils down to "what should we name this thing?" which is something everybody can easily form an opinion on. Naming bikesheds have produced some of the longest and most hotly-debated discussions about programming language design.

-Kevin Ballard

···

On Sun, Jan 3, 2016, at 04:03 PM, Erica Sadun via swift-evolution wrote:

Why has there been such a big discussion? I suspect because this is an obvious win. There's less discussion of "should there be this change" and more of "how should this be changed". The relative lightweight nature of the latter inspires lots of input. When a topic gets more technical in nature, those who are heavily invested, with expertise in building compilers and with specialized knowledge of other languages, focus the discussion.

Turns out in the end that there was an underlying "term of art" (or however that is put) along with the descriptions in the book, so there never was going to probably be anything deeper than "associatedType", "associatedtype" or "associated", in my opinion.

Why secrecy? There is none. I was asked to run a poll. I ran a poll using the best information I had at the moment. I don't have money to spend on SurveyMonkey so it cut off at 100 replies. You can't see the extra replies. I can't see the extra replies. Even playing field.

-- Erica, who had no ulterior motives

> On Jan 3, 2016, at 2:31 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
>
>
>> On Jan 3, 2016, at 10:55 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:
>>
>> I'm not opposing the proposal, but I wonder why there has been such a big discussion (and a poll whose results have neither been revealed completely nor affected the choice of the keyword)…
>>
>> Swift has proven it can thrive in secrecy, so I don't think the whole open community is a necessity — but as it is now, we should hold transparency in high esteem and not start faking democracy.
>
> I’m confused, what are you saying? No decision has been made here, I’m not aware of any “secrecy” issue.
>
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

29

Swift has proven it can thrive in secrecy, so I don't think the whole open community is a necessity — but as it is now, we should hold transparency in high esteem and not start faking democracy.

I’m confused, what are you saying? No decision has been made here, I’m not aware of any “secrecy” issue.

Sorry, it could be that my words don't express exactly what I wanted to say.
The first part is just about the closed-source past, which brought us Swift as we know it now (a big thank you for that; I'm really very happy about it).

For me (I guess for others as well :) the decision process is a black box, but I expect the proposals have impact on it — so proposers have some responsibility.
Loïc and I already had a short conversation, and I have no accusations against him, but rather wanted to criticize a tool that can be instrumentalized easily:
There has been a poll about which keyword to choose as replacement, and that made his proposal the target for my word of warning…

I guess most of us agree that surveys have to be taken with a grain of salt, and I think their use should be discouraged for most situations.
Polls itself can be manipulated in many ways (bias of the author, fake votes…), and there are no rules how to handle the result (an author could cite a survey that supports his standpoint, but he might as well ignore a result he doesn't like).

Of course, the core team is not bound to the result of any vote, but bad decisions aren't my main concern:
I don't know how this community will evolve, but I guess there will be natural controversy in the future, there will be temptation to support opinions with unfair methods — and there will be people suspecting or accusing others of using such methods…

All those bad things are most likely unavoidable, but clear rules could help keeping them at bay.

So, I hope my language has been better this time, and that Swift grows up to be a healthy open source project with a great community! (and to make sure I don't get things wrong again: It is already quite healthy and great ;-)

Best regards,
Tino

30

On a re-read I am -1; I like the `associatedtype` keyword but didn’t realize there was no plan to let `typealias` be used within a protocol to as a convenience (and to preserve intent, and to improve the development experience when still figuring out an interface design).

I would prefer the new keyword and also adding/allowing one to add convenience typealiases within a protocol definition.

I would love to see convenience typealiases supported in protocols eventually, but I actually think that should wait until after the transition to `associatedtype` is well behind us so we can get people used to the new keyword.

···

--
Brent Royal-Gordon
Architechies

31

On a re-read I am -1; I like the `associatedtype` keyword but didn’t realize there was no plan to let `typealias` be used within a protocol to as a convenience (and to preserve intent, and to improve the development experience when still figuring out an interface design).

I would prefer the new keyword and also adding/allowing one to add convenience typealiases within a protocol definition.

You can evaluate the proposal however you wish, but I don’t think it makes sense to vote against a proposal because it is missing some additional feature *unless* the lack of that additional feature makes the proposal effectively useless. I don’t think that’s the case here: changing ‘typealias’ to ‘associatedtype’ can easily be viewed as an improvement on its own, which then opens the door to additional features (real typealiases in protocols or protocol extensions).

  - Doug

···

On Jan 4, 2016, at 2:49 PM, plx via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The review of "Replace `typealias` keyword with `associatedtype` for associated type declarations” begins now and runs through Wednesday, January 6th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

32

And of course it’s not like this is taking away functionality, just not adding it yet. So sure, +1, this is still forward progress.

The fact it’s so easy to forget this other use of typealias doesn't really work in protocols right now is evidence enough for the proposal. Apologies for the double-about face.

···

On Jan 4, 2016, at 6:17 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

On a re-read I am -1; I like the `associatedtype` keyword but didn’t realize there was no plan to let `typealias` be used within a protocol to as a convenience (and to preserve intent, and to improve the development experience when still figuring out an interface design).

I would prefer the new keyword and also adding/allowing one to add convenience typealiases within a protocol definition.

I would love to see convenience typealiases supported in protocols eventually, but I actually think that should wait until after the transition to `associatedtype` is well behind us so we can get people used to the new keyword.

--
Brent Royal-Gordon
Architechies

33

   * What is your evaluation of the proposal?

+1

   * Is the problem being addressed significant enough to warrant a change to Swift?

Definitely. This is very confusing to have typealias mean two different things.

   * Does this proposal fit well with the feel and direction of Swift?

Yes. While it does add something, it simplifies and removes confusion.

   * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I haven't used similar features in other languages.

   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the review, run into the problem myself, and followed the discussion here.

34

What is your evaluation of the proposal?

In favor.

Overloading the meaning of “typealias” adds confusion to what is already a confusing feature of the language. The keyword “associatedtype” is much clearer — and much more searchable, helping newcomers to this feature discover the relevant documentation.

The words “associated type” are easily the best of any alternatives proposed. Others (“associated”, “type”, etc.) are all either too vague or too obtuse, and many are likely to cause identifier collisions. No other terminology mentioned in the discussion comes in even a close second for me.

What about the all lower case “associatedtype”? The underscore alternative of “associated_type” breaks existing language precedent. The camel case version (“associatedType”) does have language precedent, and I wonder if it wouldn’t be a better choice:

    dynamicType
    didSet
    willSet

However, there’s also precedent for making paired words all lowercase in keywords:

    typealias
    fallthrough
    deinit ←(debatable: could be considered single word or hyphenated)

Perhaps keyword capitalization conventions deserve some attention across the board.

Regardless, I can happily accept “associatedtype.”

Is the problem being addressed significant enough to warrant a change to Swift?

Certainly. Associated types clearly are a point of confusion, and active evolution. Anything that clarifies their meaning is worth considering.

Does this proposal fit well with the feel and direction of Swift?

Swift’s other keywords tend to favor the transparently descriptive (mutating, didSet) over the jargon-y (const, volatile). This change fits that tendency.

If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I haven’t, at least not enough to give useful insight..

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I loosely followed the discussion thread.

Cheers,

Paul

35

+1 from me including the preference for "associated" instead of "associatedtype"

-Thorsten

···

Am 03.01.2016 um 19:10 schrieb Alex Migicovsky via swift-evolution <swift-evolution@swift.org>:

* What is your evaluation of the proposal?

I think the proposal is great. The only thing I’d prefer is to use `associated` over `associatedtype`.

`associated` has always felt better to me over `associatedtype`. It was mentioned in one of the original proposals as the keyword that was initially most well received as well—I think this is because it just feels right, which is a good indicator even though it doesn’t seem scientific :-)

One downside mentioned is that `associated` is more vague than `associatedtype`, but there’s a reason why we don’t have `protocoltype`, `classtype`, etc as keywords over `protocol` and `class`. I think the convention of having associated type names start with an uppercase letter makes it clear that what follows `associated` is a type (or will be a concrete type).

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes, I’ve seen many developers be confused by the difference between defining a typealias inside a protocol declaration vs outside.

* Does this proposal fit well with the feel and direction of Swift?

Yes.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve been paying attention to the thread and have thought about why I like `associated` over `associatedtype` since the start of the thread.

- Alex
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

36

I think it’s more confusing (albeit not as educational) to have two different words here. For example, if I create a protocol with associated types that are used in protocol functions, then I want to implement that protocol in a class/struct tying those types to concrete types. Having two different words feels unnatural even if it is more technically accurate.

For example:

protocol ProductMaker {
    typealias Product
    func makeFoo() -> Product
}

struct FooMaker : ProductMaker {
    typealias Product = Foo
    func makeFoo() -> Product {
        return Foo()
    }
}

···

On Jan 7, 2016, at 6:55 PM, Pierre Monod-Broca via swift-evolution <swift-evolution@swift.org> wrote:

What is your evaluation of the proposal?

I'm ok

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, the current keyword is odd

  * Does this proposal fit well with the feel and direction of Swift?

Not bad, this would be my second choice if I was the only one using swift (the cz

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

N/A

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A bit more than a quick reading of the discussion

Pierre

Le 3 janv. 2016 à 07:38, Douglas Gregor <dgregor@apple.com <mailto:dgregor@apple.com>> a écrit :

Hello Swift community,

The review of "Replace `typealias` keyword with `associatedtype` for associated type declarations” begins now and runs through Wednesday, January 6th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

David James

37

Hi Erica,

sorry for the late reaction — but I've been busy writing code instead of emails ;-)

Why secrecy? There is none. I was asked to run a poll. I ran a poll using the best information I had at the moment.

I hope I could clear up some misunderstandings in the answer to Chris (no conspiracy theory here ;-) and that you don't have the impression I'm accusing you for the poll (I consider it to be an act of pure kindness).
Maybe you even agree with me partially about the potential dangers of surveys:
I still wonder why no one complained that "associated" wasn't chosen, despite being the most popular option. Sure, some may have changed their mind, but even now, there are people saying they prefer that discarded possibility.
I can think of four possible explanations for this observation (all of them with a share of "the actual keyword is so unimportant, I don't really care"):
- all changed their mind (great — everyone is happy)
- participants lost their interest and have never seen the final proposal
- participants are disappointed by the choice, but remain silent because they don't want to look like nitpickers
- participants are disappointed by the choice, but remain silent because they lost faith in the process

I guess the last one is to dramatic to be real (I've been referring to the community process; I never had much faith in polls ;-), but the first is the only one that leaves no sour taste...

Best regards,
Tino

To quash possible rumors: I personally do my nitpicking loud and proud, and I didn't start this tiny meta-discussion in frustration — as long as I only have to use the word with working autocompletion, "associatedtype" is fine for me ;-)

38

+1 In the original discussion I was advocating generics as the way forward

···

On Tue, Jan 12, 2016 at 10:19 AM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote:

I have proposed the elimination of associated types by replacing them with
generic arguments and an implementation of generics that allows covariance,
see:

[swift-evolution] Make generics covariant and add generics to protocols
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006367.html&gt;

Food for though for another way forward?

PS I agree using typealias for two different concepts is confusing.

On 3 Jan 2016, at 5:38 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "Replace `typealias` keyword with `associatedtype` for
associated type declarations” begins now and runs through Wednesday,
January 6th. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Cheers,
Doug Gregor
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
 Wizard
james@supmenow.com
+44 7523 279 698

39

I have proposed the elimination of associated types by replacing them with generic arguments and an implementation of generics that allows covariance, see:

  [swift-evolution] Make generics covariant and add generics to protocols <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006367.html&gt; <>

Food for though for another way forward?

FWIW, I disagree fairly strongly with both of those directions for Swift generics; I’ll reply over on that thread.

  - Doug

···

On Jan 12, 2016, at 2:19 AM, Howard Lovatt <howard.lovatt@gmail.com> wrote:

PS I agree using typealias for two different concepts is confusing.

On 3 Jan 2016, at 5:38 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The review of "Replace `typealias` keyword with `associatedtype` for associated type declarations” begins now and runs through Wednesday, January 6th. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

  Cheers,
  Doug Gregor
  Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

40

LOL

I don't think my you can get a stronger +1 for removing this than "reviewer doesn't understand the feature"!

···

On Jan 3, 2016, at 5:41 AM, Loïc Lecrenier <loiclecrenier@icloud.com> wrote:

Hi Drew,

Thanks for the review, just a quick remark:

“Real” type aliases are already forbidden inside protocols, so this proposal wouldn’t change that.
(According to the grammar, a protocol body can only contain: property, method, initializer, subscript, or associated type member declarations)

In your example, secondstype and usecstype were associated types with initial values. To convince yourself, try to create this function
func bar(_: Foo) { }
and you should see the "can only be used as a generic constraint because it has Self or associated type requirements” error.

I initially wanted to allow type aliases inside protocols, and I was told type aliases weren’t requirements, so they shouldn’t be defined inside protocols, which makes sense to me.

We might want to reconsider this, but I think it is outside the scope of this proposal.

Loïc

On Jan 3, 2016, at 11:46 AM, Drew Crawford via swift-evolution <swift-evolution@swift.org> wrote:

   * What is your evaluation of the proposal?

+1

   * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. A typealias in a protocol and a typealias anywhere else are 2 very different things.

* One is almost a preprocessor macro
* The other basically defines the protocol as a generic type, which has a lot of strange follow-on consequences

There are plenty of questions online related to this confusion.

In addition the change is trivial and code could be transitioned automatically.

   * Does this proposal fit well with the feel and direction of Swift?

The choice of keyword "associatedtype" is already used in a common compiler error message:

protocol 'Printable' can only be used as a generic constraint because it has Self or associated type requirements

Using "associatedtype" here is consistent with that error message and makes it more understandable for new users.

   * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I am an occasional user of Rust; Rust uses the same keyword ("type") in both of these cases. IMO that choice is suffers from the same problems in Rust that it does here.

   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

One "potential" problem with this proposal is that it technically forbids the use of a "real" typealias in a protocol e.g.

protocol Foo {
   typealias F = Int
}

is now illegal.

To evaluate the severity of this problem I checked a private codebase with 47 usages of typealias. One usage of the 47 would be illegal:

protocol Foo {
     if arch(x86_64) || arch(arm64)
               typealias secondstype = Int64
               typealias usecstype = Int64
         #else
               typealias secondstype = __darwin_time_t
               typealias usecstype = __darwin_suseconds_t
          #endif
   func setTimeout(s: secondstype, u: usecstype) throws
}

I refactored this to move the typealiases to top level. That is not ideal, but I think it is outweighed by the advantages of this proposal.

While auditing this codebase for illegal typealiases I did find a comment that was quite confused about the difference between typealias and associatedtype. So that convinces me even more about the importance of this proposal.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution