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

Douglas_Gregor · 2016-01-03T06:38:27.000Z

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:

swift-evolution/0011-replace-typealias-associated.md at master · apple/swift-evolution · GitHub

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

swift-evolution/process.md at master · apple/swift-evolution · GitHub

  Cheers,
  Doug Gregor
  Review Manager

Brent_Royal-Gordon · 2016-01-03T07:04:41.000Z

* What is your evaluation of the proposal?

I think it's a great idea. The shift in meaning when you use `typealias` in a protocol is enormous—not only is an associated type far more different from a typealias than most protocol requirements, but it also changes the way you can use the protocol itself—and sharing a keyword gives you no hint of that. It also means that you can't search the documentation for the keyword to understand what it means. Switching to an `associatedtype` keyword fixes these issues.

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

Absolutely. I have seen nothing but confusion surrounding the use of associated types in protocols, and anything that might clear that up is a great idea.

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

Yes. Swift typically doesn't shy away from introducing new keywords to accurately capture semantics, and that's what `associatedtype` does.

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

I have not used any such languages.

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

I've participated in some of the discussions of this proposal, particularly the discussion of alternative keywords. There I advocated `associated`, but I will admit that `associatedtype` is slightly clearer.

···

--
Brent Royal-Gordon
Architechies

Lily_Ballard · 2016-01-03T07:48:25.000Z

* What is your evaluation of the proposal?

+1

I have a preference for `associated` instead of `associatedtype`, but
it's not a big deal.

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

Personally I don't think it's a particularly significant problem, but it
is a small one that this change would help with, and the change itself
is pretty minor (and can be automated in 100% of cases).

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

Yes.

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

Rust has the same feature, although it uses the keyword `type` instead
of `typealias`. And they still use the same keyword `type` for
associated types inside of traits. But rust uses associated types much
more sparingly than Swift does (Rust traits can have generic type
parameters, and in fact associated types were a fairly late addition to
the language). Swift is also much more of a teaching language than Rust
is, so I think this change is quite reasonable for Swift.

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

I followed the original swift-evolution thread and read the proposal
again just now.

-Kevin Ballard

···

On Sat, Jan 2, 2016, at 10:38 PM, Douglas Gregor wrote:

Drew_Crawford1 · 2016-01-03T10:46:09.000Z

* 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 <ios - How to use generic protocol as a variable type - Stack Overflow; of questions <Redirecting to Google Groups; 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.

plx · 2016-01-03T12:27:44.000Z

I like this.

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.

···

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

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

anandabits · 2016-01-03T14:47:25.000Z

* What is your evaluation of the proposal?

I like this proposal. I think it adds clarity to the language. Especially after the change from 'associated' to 'associatedtype'.

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

Yes. It isn't a huge issue for me but has causes confusion for some. A distinct keyword improving clarity is worth the change.

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

Yes.

* 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 familiar with several. This proposal is different than anything I've see, but in a good way.

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

I read the proposal, followed the discussion, and thought about the tradeoffs.

dwaite · 2016-01-03T16:27:25.000Z

* What is your evaluation of the proposal?

+1, with caveats

From a wording perspective, the “Proposed Approach” and “Impact on Existing Code” sections talk about removing typealias, while the intention is almost certainly to remove typealias usage within protocols only. My review assumes the latter.

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

I think it is based on Swift today, in particular for the reasons given in the proposal (that it looks like, but is not possible, to use typealias to declare a type alias inside a protocol)

I personally find it cumbersome that Swift does not allow protocols with associated types to be used other than under generic constraints - I would prefer generic protocols. If generic protocols were on the horizon, then I do not know whether declaring associated types inline is even a necessary feature.

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

Yes, although I still feel the keyword is long.

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

Since Swift is the only language I have used with associated types, I can only compare to Swift 1 and 2. I feel this will make the protocols themselves easier to understand

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

I followed the mailing list for the most part, read the proposal, and imagined adding it to my own protocols.

-DW

migi · 2016-01-03T18:10:20.000Z

* 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

Janosch_Hildebrand · 2016-01-03T13:42:51.000Z

* What is your evaluation of the proposal?

I am in favor of this for the same reasons mentioned by the previous reviewers.

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

Yes.

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

I think so.

* 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 only aware of Rust and I haven't used that enough to make any meaningful comparisons.

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

I read the proposal and followed the previous threads discussing the proposal and the keyword.

Speaking of which, `associatedtype` remains my favorite. I don't think its ideal but I prefer it to the alternatives that were considered.

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

- Janosch

···

On 03 Jan 2016, at 07:38, Douglas Gregor <dgregor@apple.com> wrote:

salutis · 2016-01-03T17:18:08.000Z

  * 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

salutis · 2016-01-03T17:21:46.000Z

Sorry for the previous message. I pressed “Send” by mistake...

Here is my +1:

* What is your evaluation of the proposal?

It’s a great improvement.

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

Definitely.

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

Yes.

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

No.

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

I followed the discussion closely.

···

—

Rudolf Adamkovic

R+

Tino · 2016-01-03T18:55:10.000Z

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.

Just my 2c
Tino

Jo_Albright1 · 2016-01-04T14:40:45.000Z

- What is your evaluation of the proposal?

+1 : I am all for the idea of not using the same word for different functionalities. I don’t see any upside to keeping it the way it is.

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

Description of Swift includes “Swift is designed to make writing and maintaining correct programs easier for the developer”… if the desire is to make the language easy to understand and learn, then this is a very important change as it removes confusion.

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

100%

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

I have not come across this type of feature before.

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

I read all of the reviews and proposal thoroughly.

···

---

Really excited to see how many people come out to give their opinions on proposals. Hope my words are helpful.

Jo Albright

mwhiteside.dev · 2016-01-04T17:47:49.000Z

* What is your evaluation of the proposal?

Taking an example from the swift source to compare an alternative, `type`, we have

public protocol _CollectionWrapperType : _SequenceWrapperType {
associatedtype Base : CollectionType
associatedtype Index : ForwardIndexType = Self.Base.Index
}

vs

public protocol _CollectionWrapperType : _SequenceWrapperType {
type Base : CollectionType
type Index : ForwardIndexType = Self.Base.Index
}

I think the version with `associatedtype` is a bit verbose, but that doesn’t seem like a big problem. It might read a little more clearly as well. I wouldn’t be unhappy with either of these alternatives, but `associatedtype` seems like a good choice.

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

Yes. I think it `typealias` should be used only as the swift equivalent of a C typedef.

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

Yes, because we want to improve readability and understandability.

* 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 another language with this feature.

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

In depth study.

···

On Jan 2, 2016, at 22:38, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

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

hagi · 2016-01-04T09:57:11.000Z

* What is your evaluation of the proposal?

+1. Solves a real problem I’ve come across before.

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

Yes, because the problem can cause serious frustration, for beginners in particular.

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

Yes, because readability is improved. No need to consider the context anymore, the keyword itself makes it very clear what is declared.

* 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 any language with a comparable feature.

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

I’ve read the review carefully and followed the prior discussion briefly.

plx · 2016-01-04T22:49:02.000Z

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 have not followed the discussion closely to know if there are difficult technical issues with permitting both `associatedtype` declarations and simple convenience `typealias` declarations within a protocol, or if the current proposal is simply making the possible-confusion argument; if there are legit technical issues then so be it, but if it’s just an argument-from-possible-confusion I think the price of clarity is dearer than it needs to be here.

···

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?
  * 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

cryo · 2016-01-04T17:05:26.000Z

* What is your evaluation of the proposal?

+1, although I don’t like the name because it’s two normally non-compoundable words, compounded into one. A combination that would be more natural is something like “typeassociate” although that sounds quite silly to me. I suppose maybe just “associated”.

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

Yes, it has seemed to confuse people on several occasions.

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

Yes, I believe so.

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

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

I followed the discussion closely and, while it doesn’t confuse me personally, I have seen several mails and forum posts from people it does.

/Sune

jtbandes · 2016-01-06T05:42:13.000Z

What is your evaluation of the proposal?

+1 for changing the name, but -1 for "associatedtype" in particular.
Alternate suggestions:

   - associatedType Element
   - associated_type Element
   - associated type Element
   - associated Element
   - type Element
   - having Element

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

Swift?

Yes.

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

I don't feel that the multi-word-yet-all-lowercase name fits with the rest
of the Swift language. See alternate suggestions above.

How much effort did you put into your review? A glance, a quick reading,

or an in-depth study?

Extensive experience with the feature, but I have mostly just skimmed the
emails in this (and the preceding) thread.

- Jacob

···

On Sat, Jan 2, 2016 at 10: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

Krzysztof_Siejkowski · 2016-01-06T10:17:16.000Z

Hello!

* What is your evaluation of the proposal?
+1, due to the already stated reasons: difference in meanings, better expression of the associated types construct etc. I also do like the `associatedtype` keyword proposal and I’ve yet to see any better alternatives in the discussion.

* Is the problem being addressed significant enough to warrant a change to Swift?
Yes. The change reflects the gravity of the problem, which is limited in terms of source-compatibility, but significant in terms of programmers’ understanding and being beginners friendly.

* Does this proposal fit well with the feel and direction of Swift?
I do feel so. Looking at already posted „Swift philosophy” summary: "Provide a programmer model that: is high level; is expressive and clean” I believe the change makes the high-level concept of associated types expressive and clean in the code.

* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I’ve been using „abstract type members” in Scala traits, which are a very similar concept. Frankly, I believe that Swift „associated type” naming is less confusing than „abstract type”. Also, Scala uses „type” keyword with is not descriptive enough for me. Again, I like „associatedtype” better.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I’ve been closely following the discussion(s) on the swift-evolution list and I’ve read the proposal. While I haven't done any in-depth literature study, I’ve been cross-comparing the proposed solution with my knowledge/experience in Scala.

Cheers,

Krzysztof Siejkowski

possen · 2016-01-06T22:54:38.000Z

* What is your evaluation of the proposal?

This definitely makes the two concepts much more easy to understand. Overloading the meanings is confusing. Separating them helps a lot.

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

Definitely.

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

Yes

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

Not applicable

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

Read the proposal and followed some of the discussion on the swift-evolution list.

···

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