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

[Erica_Sadun]

+1 from me too.

(My vote takes into account the various alternatives were put on the table and weeded down thoughtfully to the one we're voting on.)

-- E

···

On Jan 3, 2016, at 5:57 AM, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

+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 <mailto: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 <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?

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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[Lily_Ballard]

I agree that protocols shouldn't have typealiases, but I would be in favor of protocol extensions having them:

extension SequenceType {
    typealias Element = Generator.Element
}

But it is definitely outside the scope of this proposal.

-Kevin Ballard

···

On Sun, Jan 3, 2016, at 03:41 AM, Loïc Lecrenier via swift-evolution 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.

[Chris_Lattner]

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.

No problem at all, I just wanted to clarify your meaning and intention, thanks!

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.

There is no simple answer here. Core team members are humans and have different things that impact and motivate them. We intentionally want Swift to have a common “center of gravity” and be an “opinionated” language, rather than fall to the “design by committee” approach that leads to a watered-down design. This means that decisions are really all shades of gray and cannot be specified or predicted by algorithm. We aim to be as transparent as possible, and explain the rationale for decisions when they come out.

That said, I and many other people on the team are highly motivated and effected by clear descriptions of problems being solved, and why current approaches are wrong. Particularly moving are things written by people who are clearly familiar with Swift as it stands, and who speak to why a change will make Swift better. Someone saying “I saw thing X in language Y, so we should transplant it to Swift” - with no further justification - is not very motivating, because Swift is much different than any other language Y, and so the tradeoffs that make it compelling in Y may not translate over to make it compelling in Swift.

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 ;-)

Me too. We are definitely all new to this and learning as we go along. I’m sure that we’ll all make mistakes, but we aim to learn from them and adapt & change when we do. Please have patience as this inevitably happens, it is because we’re just humans, and all jointly trying to make Swift as great as we can!

-Chris

···

On Jan 3, 2016, at 3:43 PM, Tino Heth <2th@gmx.de> wrote:

[Loic_Lecrenier (Loïc Lecrenier)]

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.

I thought the rules were:
- property/method: lowerCamelCase
- language keyword: lowercase

I consider
- dynamicType as a property
- didSet, willSet, deinit as methods.
- typealias, fallthrough as language keywords

And “associatedtype” would be a language keyword too, so it is lowercase

Loïc

[anandabits (Matthew Johnson)]

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()
    }
}

Most of the time, including this example, you do not need to declare the typealias. It will be inferred by the compiler.

···

On Jan 7, 2016, at 12:22 PM, David James via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 7, 2016, at 6:55 PM, Pierre Monod-Broca via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

David James

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

[Alex_Popov]

Data of 1: I am disappointed by the choice, but remain silent so I don't look like a nit picker and to not further clutter the mailing list.
I find `associatedtype` to be clearer, but `associated` to be much more pleasant to read and write.
* What is your evaluation of the proposal?
+1 for the proposal, I didn't know associated types in protocols where even a thing, I just thought it was black-typealias-magic that was out of my intellectual reach.
* 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?
I do believe this proposal fits well with Swift, regardless of keyword chosen.
* 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?
I have been following the proposal from the start, and have read up on Associated Types in protocols.

Alex Popov Jr.
Principal iOS developer | Shelfie
www.shelfie.com | @getshelfie

···

_____________________________
From: Tino Heth via swift-evolution <swift-evolution@swift.org>
Sent: Thursday, January 7, 2016 15:22
Subject: Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations
To: Erica Sadun <erica@ericasadun.com>
Cc: Swift Evolution <swift-evolution@swift.org>

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 ;-)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[hartbit (David Hart)]

I also really like the proposal but prefer the ‘associated’ keyword instead of ‘associatedtype’. Here is my review:

What is your evaluation of the proposal?

Big +1 from me. I remember that the typealias keyword in protocols confused me for quite a while: the concept of associated types is already complicated to grasp coming from a different generics model, but overloading the typealias keyword doesn’t help in the learning process. Like I said above, I would vote for the ‘associated’ keyword. Even if grammatically more correct, ‘associatedtype’ seems like a mouthful for me.

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

I strongly think so.

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?

After learning about associated types, I researched Scala traits and it helped me understand the concept better and enjoyed that Scala uses a clearly defined keyword.

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

I followed the original discussion but haven’t found time to read all reviews before mine.

···

On 08 Jan 2016, at 01:13, Alex Popov via swift-evolution <swift-evolution@swift.org> wrote:

Data of 1: I am disappointed by the choice, but remain silent so I don't look like a nit picker and to not further clutter the mailing list.

I find `associatedtype` to be clearer, but `associated` to be much more pleasant to read and write.

* What is your evaluation of the proposal?

+1 for the proposal, I didn't know associated types in protocols where even a thing, I just thought it was black-typealias-magic that was out of my intellectual reach.

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

I do believe this proposal fits well with Swift, regardless of keyword chosen.

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

I have been following the proposal from the start, and have read up on Associated Types in protocols.

Alex Popov Jr.
Principal iOS developer | Shelfie
www.shelfie.com <Domain parked by Instra; | @getshelfie

_____________________________
From: Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
Sent: Thursday, January 7, 2016 15:22
Subject: Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations
To: Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>>
Cc: Swift Evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>

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 ;-)
_______________________________________________
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

[jtbandes (Jacob Bandes-Storch)]

I'm sure we're just bikeshedding at this point, but...

I find "typealias" and "fallthrough" much easier to read, and easier to
write, than "associatedtype". Upon further in(tro)spection, I think I'm
reading typealias and fallthrough as compound words
<https://en.wikipedia.org/wiki/English_compound&gt;, rather than multiple
words with no separation, so there is no question that they should be
all-lowercase.

I find associatedtype harder to interpret as a compound word, so I'd expect
some separation, either associated_type or associatedType. (I put some
other suggestions that I like better in my previous email, though.)

Jacob

···

On Wed, Jan 6, 2016 at 12:56 PM, Loïc Lecrenier <swift-evolution@swift.org> wrote:

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

I thought the rules were:
- property/method: lowerCamelCase
- language keyword: lowercase

I consider
- dynamicType as a property
- didSet, willSet, deinit as methods.
- typealias, fallthrough as language keywords

And “associatedtype” would be a language keyword too, so it is lowercase

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

[Paul_Cantrell]

Those are all language keywords.

Complete list here: The Swift Programming Language: Redirect

P

···

On Jan 6, 2016, at 2:56 PM, Loïc Lecrenier <loiclecrenier@icloud.com> wrote:

Perhaps keyword capitalization conventions deserve some attention across the board.

I thought the rules were:
- property/method: lowerCamelCase
- language keyword: lowercase

I consider
- dynamicType as a property
- didSet, willSet, deinit as methods.
- typealias, fallthrough as language keywords

[rdemarest (Remy Demarest)]

Perhaps keyword capitalization conventions deserve some attention across the board.

I thought the rules were:
- property/method: lowerCamelCase
- language keyword: lowercase

I consider
- dynamicType as a property
- didSet, willSet, deinit as methods.
- typealias, fallthrough as language keywords

Those are all language keywords.

Complete list here: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/doc/uid/TP40014097-CH30-ID413

P

I think he was talking about how those keywords were used in the language. However, to me it just looks like post-hoc rationalization.

···

Le 06 janv. 2016 à 22:03, Paul Cantrell via swift-evolution <swift-evolution@swift.org> a écrit :

On Jan 6, 2016, at 2:56 PM, Loïc Lecrenier <loiclecrenier@icloud.com> wrote:

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

[Ross_O_Brien]

It seems no different to me than when "instancetype" was added to Objective
C (though, that doesn't say anything for the 'Swiftiness' of it).

Ross

···

On Wed, Jan 6, 2016 at 9:08 PM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote:

I'm sure we're just bikeshedding at this point, but...

I find "typealias" and "fallthrough" much easier to read, and easier to
write, than "associatedtype". Upon further in(tro)spection, I think I'm
reading typealias and fallthrough as compound words
<https://en.wikipedia.org/wiki/English_compound&gt;, rather than multiple
words with no separation, so there is no question that they should be
all-lowercase.

I find associatedtype harder to interpret as a compound word, so I'd
expect some separation, either associated_type or associatedType. (I put
some other suggestions that I like better in my previous email, though.)

Jacob

On Wed, Jan 6, 2016 at 12:56 PM, Loïc Lecrenier <swift-evolution@swift.org > > wrote:

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

I thought the rules were:
- property/method: lowerCamelCase
- language keyword: lowercase

I consider
- dynamicType as a property
- didSet, willSet, deinit as methods.
- typealias, fallthrough as language keywords

And “associatedtype” would be a language keyword too, so it is lowercase

Loïc
_______________________________________________
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

[James_Campbell]

What about protocoltype ?

···

Sent from my iPhone

On 6 Jan 2016, at 22:33, Ross O'Brien via swift-evolution <swift-evolution@swift.org> wrote:

It seems no different to me than when "instancetype" was added to Objective C (though, that doesn't say anything for the 'Swiftiness' of it).

Ross

On Wed, Jan 6, 2016 at 9:08 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> wrote:
I'm sure we're just bikeshedding at this point, but...

I find "typealias" and "fallthrough" much easier to read, and easier to write, than "associatedtype". Upon further in(tro)spection, I think I'm reading typealias and fallthrough as compound words, rather than multiple words with no separation, so there is no question that they should be all-lowercase.

I find associatedtype harder to interpret as a compound word, so I'd expect some separation, either associated_type or associatedType. (I put some other suggestions that I like better in my previous email, though.)

Jacob

On Wed, Jan 6, 2016 at 12:56 PM, Loïc Lecrenier <swift-evolution@swift.org> wrote:
>
> 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.

I thought the rules were:
- property/method: lowerCamelCase
- language keyword: lowercase

I consider
- dynamicType as a property
- didSet, willSet, deinit as methods.
- typealias, fallthrough as language keywords

And “associatedtype” would be a language keyword too, so it is lowercase

Loïc
_______________________________________________
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

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