Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Lyle Parkyn via swift-evolution]

1. What is your evaluation of the proposal?
I think the proposal has merit. It seeks to clarify a possible confusing issue. 

I’m late to this issue, however, and perhaps because I read through everything 
in one go, but the keyword that came to me was “conformancetype”.
We’re talking protocols and protocols are about conformance - including the use 
a particular type within the protocol.

Although it looks longer “conformancetype” it is only one character more than 
“associatedtype" 

2. Is the problem being addressed significant enough to warrant a change to 
Swift?
I agree the change is warranted.

3. Does this proposal fit well with the feel and direction of Swift?
I believe it does fit well with the feel and direction of the language.

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

5. How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I studied the proposal and discussions.

6. Please state explicitly whether you believe that the proposal should be 
accepted into Swift.

I think proposal should be accepted. 


- Lyle Parkyn
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Ross O'Brien via swift-evolution]

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Paul Ossenbruggen via swift-evolution]

> On Jan 2, 2016, at 10:38 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
>   * 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. 


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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Paul Cantrell via swift-evolution]

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

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Paul Cantrell via swift-evolution]

> On Jan 6, 2016, at 2:56 PM, Loïc Lecrenier  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

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Jacob Bandes-Storch via swift-evolution]

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Loïc Lecrenier via swift-evolution]

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Jacob Bandes-Storch via swift-evolution]

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[plx via swift-evolution]

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

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[plx via swift-evolution]

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Brent Royal-Gordon via swift-evolution]

> 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

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 2:49 PM, plx via swift-evolution 
>  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.

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 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution 
>> > 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

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Jo Albright via swift-evolution]

- 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

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Sune Foldager via swift-evolution]

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

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Matt Whiteside via swift-evolution]

> On Jan 2, 2016, at 22:38, Douglas Gregor via swift-evolution 
>  wrote:
>   * 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.

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Erica Sadun via swift-evolution]

+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 
>  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 
> > wrote:
> I like this.
> 
>> On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution 
>> > 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 
> 
> 
> 
>  ___
> 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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Tino Heth via swift-evolution]

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Kevin Ballard via swift-evolution]

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 
> >  wrote:
> > 
> > 
> >> On Jan 3, 2016, at 10:55 AM, Tino Heth via swift-evolution 
> >>  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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[David Waite via swift-evolution]

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[plx via swift-evolution]

I like this.

> On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution 
>  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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[T.J. Usiyan via swift-evolution]

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

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Tino Heth via swift-evolution]

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

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

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

[Douglas Gregor via swift-evolution]

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