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