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

[Drew Crawford]

LOL

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

> On Jan 3, 2016, at 5:41 AM, Loïc Lecrenier <loiclecrenier at icloud.com> wrote:
> 
> Hi Drew,
> 
> Thanks for the review, just a quick remark:
> 
> “Real” type aliases are already forbidden inside protocols, so this proposal wouldn’t change that.
> (According to the grammar, a protocol body can only contain: property, method, initializer, subscript, or associated type member declarations)
> 
> In your example, secondstype and usecstype were associated types with initial values. To convince yourself, try to create this function
> func bar(_: Foo) { }
> and you should see the "can only be used as a generic constraint because it has Self or associated type requirements” error.
> 
> I initially wanted to allow type aliases inside protocols, and I was told type aliases weren’t requirements, so they shouldn’t be defined inside protocols, which makes sense to me.
> 
> We might want to reconsider this, but I think it is outside the scope of this proposal.
> 
> Loïc
> 
>> On Jan 3, 2016, at 11:46 AM, Drew Crawford via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> 
>>>    * What is your evaluation of the proposal?
>> 
>> +1
>> 
>>>    * Is the problem being addressed significant enough to warrant a change to Swift?
>> 
>> Yes.  A typealias in a protocol and a typealias anywhere else are 2 very different things.
>> 
>> * One is almost a preprocessor macro
>> * The other basically defines the protocol as a generic type, which has a lot of strange follow-on consequences
>> 
>> There are plenty of questions online related to this confusion.
>> 
>> In addition the change is trivial and code could be transitioned automatically.
>> 
>>>    * Does this proposal fit well with the feel and direction of Swift?
>> 
>> The choice of keyword "associatedtype" is already used in a common compiler error message:
>> 
>>> protocol 'Printable' can only be used as a generic constraint because it has Self or associated type requirements
>> 
>> Using "associatedtype" here is consistent with that error message and makes it more understandable for new users.
>> 
>>>    * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> 
>> I am an occasional user of Rust; Rust uses the same keyword ("type") in both of these cases.  IMO that choice is suffers from the same problems in Rust that it does here.
>> 
>>>    * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
>> One "potential" problem with this proposal is that it technically forbids the use of a "real" typealias in a protocol e.g.
>> 
>> protocol Foo {
>>    typealias F = Int
>> }
>> 
>> is now illegal.
>> 
>> To evaluate the severity of this problem I checked a private codebase with 47 usages of typealias.  One usage of the 47 would be illegal:
>> 
>> protocol Foo {
>>      #if arch(x86_64) || arch(arm64)
>>                typealias secondstype = Int64
>>                typealias usecstype = Int64
>>          #else
>>                typealias secondstype = __darwin_time_t
>>                typealias usecstype = __darwin_suseconds_t
>>           #endif
>>    func setTimeout(s: secondstype, u: usecstype) throws
>> }
>> 
>> I refactored this to move the typealiases to top level.  That is not ideal, but I think it is outweighed by the advantages of this proposal.
>> 
>> While auditing this codebase for illegal typealiases I did find a comment that was quite confused about the difference between typealias and associatedtype.  So that convinces me even more about the importance of this proposal.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>