[swift-evolution] Introduce "associated_type" keyword

[Alex Lew]

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>
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>
> wrote:
> >
> > I have drafted a formal proposal here:
> 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> wrote:
> >>
> >>> On Dec 5, 2015, at 4:35 PM, Loïc Lecrenier via swift-evolution <
> 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
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151206/33c3a364/attachment.html>