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

[Loïc Lecrenier]

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