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