[swift-evolution] Introduce "associated_type" keyword

Sun Dec 6 13:25:54 CST 2015

Yes, I mean “deprecate typealias” only in the context of associated types. Will clarify, thanks :)

As for forbidding the default behavior, I don’t think I’m qualified enough to answer that. 
At first glance, it seems to make sense.

However, I feel like this deserves to be an other proposal, after this one is (hopefully!) accepted.
Because currently the proposal is extremely simple: it is about replacing one keyword 
with another one, in order to improve the clarity of the grammar. Moreover, the transition 
from the previous grammar to the proposed one is immediate.

Changes to the places where (associated types / type aliases) are allowed will involve more 
technical discussions, may be more controversial, and may complicate the review of the proposal.

So, unless someone familiar with the inner workings of Swift tells me that allowing 
“associated ___ = ___” in protocol extensions is an obvious consequence of adding the 
`associated` keyword, I would rather not include it in the proposal. 

Happy to hear any counter-argument, though :)

Loïc 

> On Dec 6, 2015, at 7:34 PM, Alex Lew <alexl.mail+swift at gmail.com> wrote:
> 
> Commented on the proposal but realize that it might be better to reply here. 
> 
> For clarification: when you say "deprecate typealias" do you mean only in the context of associated types or in the language as a whole?
>  
> I also thought it might make sense to add to the proposal a disabling of the "default" behavior that is currently allowed for type aliases in protocols:
> 
> protocol Prot {
>     associated Container: SequenceType
>     associated Element = Container.Generator.Element // should be illegal
> }
> 
> Instead, if you actually want the semantics of an additional associated type with a default (but overridable) value, you should use a protocol extension. (Which means that associated ____ = ____ would be allowed in protocol extensions, but not associated ____ : _____  or associated ____ : ____ = _____.) Does that sound right?
> 
> 
> On Sun, Dec 6, 2015 at 10:32 AM, Loïc Lecrenier <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Well, I went ahead and created a pull request :)
> 
> I also included a “proposed approach” section, where I propose to deprecate
> the `typealias` keyword for Swift 2.2, and replace it entirely for Swift 3.0.
> 
> Does anyone have any thought on that? This is a bit aggressive, but I think it’s worth it.
> It is actually the same approach Erica proposed for removing C for-loops.
> 
> Loïc
> 
> > On Dec 6, 2015, at 1:12 PM, Loïc Lecrenier <loiclecrenier at icloud.com <mailto:loiclecrenier at icloud.com>> wrote:
> >
> > I have drafted a formal proposal here: https://gist.github.com/loiclec/22459d230a21dbcb81fc <https://gist.github.com/loiclec/22459d230a21dbcb81fc>
> > Would love to receive feedback from the community on it, I am particularly worried about the correctness of the terms I used.
> > Should I make a pull request to swift-evolution now, or should we continue the conversation here?
> >
> > Thanks,
> >
> > Loïc
> >
> > (and sorry about emailing you on Sunday 😇 )
> >
> >> On Dec 6, 2015, at 1:48 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
> >>
> >>> On Dec 5, 2015, at 4:35 PM, Loïc Lecrenier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >>> Hi everyone :)
> >>>
> >>> I propose introducing a new "associated_type" keyword that will replace "typealias" for declaring associated types in protocols.
> >>> I remember being confused by associated types when I started using Swift, and I think one reason why was the use of the typealias keyword to define them.
> >>> One reason was that I thought I knew what typealias did, and so I didn't stop to learn what it did inside a protocol. An other reason was the difficulty of finding help when searching for "typealias" instead of "associated types".
> >>> Then, when I thought I understood it, I started building an excessively protocol-oriented program as an exercise. And I still lost a lot of time fighting Swift by trying to use "real" typealias-es inside of protocols.
> >>>
> >>> Conceptually, I had something like this:
> >>>
> >>> protocol ProtA {
> >>> typealias Container : SequenceType
> >>> }
> >>> protocol ProtB {
> >>> typealias AnOtherAssocType : ProtA
> >>> func foo(x: AnOtherAssocType.Container.Generator.Element, y: AnOtherAssocType.Container.Generator.Element) -> AnOtherAssocType.Container.Generator.Element
> >>> }
> >>>
> >>> The function foo is very difficult to read, so I wanted to use a shortcut to Element by doing this:
> >>>
> >>> protocol ProtB {
> >>> typealias A : ProtA
> >>> typealias Element = A.Container.Generator.Element
> >>> func foo(x: Element, y: Element) -> Element
> >>> }
> >>>
> >>> But by doing so, I didn't create a shortcut to Element, but an associated type with a default value of Element. (right?)
> >>> Then I tried to write extensions to ProtB where Element conforms to, say, Equatable, and couldn't make it work because A.Container.Generator.Element didn't conform to Equatable.
> >>>
> >>> So, that was a rather long explanation of the reasons I think we should replace the typealias keyword by associated_type, and allow "real" typealias-es inside protocols.
> >>
> >> I think this is a great idea; re-using typealias for associated types was a mistake.
> >>
> >> John.
> >>
> >>>
> >>> Ideally, I would write
> >>>
> >>> protocol ProtB {
> >>> associated_type AnOtherAssocType : ProtA
> >>> typealias Element = AnOtherAssocType.Container.Generator.Element
> >>> func foo(x: Element, y: Element) -> Element
> >>> }
> >>>
> >>> and it would be exactly the same as
> >>>
> >>> protocol ProtB {
> >>> associated_type AnOtherAssocType : ProtA
> >>> func foo(x: A.Container.Generator.Element, y: A.Container.Generator.Element) -> A.Container.Generator.Element
> >>> }
> >>>
> >>> There are probably some problems created by this proposal, but right now I can't see any :/
> >>>
> >>> Thanks,
> >>>
> >>> Loïc
> >>> _______________________________________________
> >>> swift-evolution mailing list
> >>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 