Introduce "associated_type" keyword

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.

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

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.

···

On Dec 5, 2015, at 4:35 PM, Loïc Lecrenier via swift-evolution <swift-evolution@swift.org> wrote:

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

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.

Agreed.

-Chris

···

On Dec 5, 2015, at 4:48 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 5, 2015, at 4:35 PM, Loïc Lecrenier via swift-evolution <swift-evolution@swift.org> wrote:

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

I like "associated". Or maybe "withtype". Anything clear and without underscore.

protocol Foo {
   associated T
}

protocol Foo {
  withtype T
}

···

On Dec 5, 2015, at 5:43 PM, Stephen Celis via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 5, 2015, at 8:11 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

If we must keep this concept, I would prefer something without an underscore for the keyword, like "associatedtype" or perhaps "typeassociation"

Or merely "associated".
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1 to the proposal, emphasizing the distinction is important; and I
like "associated" as the keyword for this purpose, too.

Dmitri

···

On Sat, Dec 5, 2015 at 5:43 PM, Stephen Celis via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 5, 2015, at 8:11 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

If we must keep this concept, I would prefer something without an underscore for the keyword, like "associatedtype" or perhaps "typeassociation"

Or merely "associated".

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

I like the proposal in general, but the snake case feels decidedly un-Swifty (although I like snake case personally it isn't the Swift convention and I do like strong conventions).

···

Sent from my iPad

On Dec 5, 2015, at 7:46 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

I like "associated". Or maybe "withtype". Anything clear and without underscore.

protocol Foo {
  associated T
}

protocol Foo {
withtype T
}

On Dec 5, 2015, at 5:43 PM, Stephen Celis via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 5, 2015, at 8:11 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

If we must keep this concept, I would prefer something without an underscore for the keyword, like "associatedtype" or perhaps "typeassociation"

Or merely "associated".
_______________________________________________
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

Is it possible to do away with associated types and just use plain generic type declarations instead? This is one thing that kind of confuses me about the generics system. Coming from Java and c#, interfaces there are generic in the same way that classes (and structs in c#) are, and there are a lot of nice things we could get along with that if protocols were generic as part of their type declaration. Is there a compelling (technical or otherwise) reason to keep associated types as they are (to the exclusion of generic parameters) today that I'm missing?

If we must keep this concept, I would prefer something without an underscore for the keyword, like "associatedtype" or perhaps "typeassociation"

···

--
Kevin Lundberg

On Dec 5, 2015, at 7:48 PM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 5, 2015, at 4:35 PM, Loïc Lecrenier via swift-evolution <swift-evolution@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@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

Or merely "associated".

···

On Dec 5, 2015, at 8:11 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

If we must keep this concept, I would prefer something without an underscore for the keyword, like "associatedtype" or perhaps "typeassociation"

Right. I proposed associated_type simply because that's what SIL calls them, but it is a bad name for Swift. I like associated and withtype though.

Loïc

···

On Dec 6, 2015, at 3:08 AM, Anandabits <matthew@anandabits.com> wrote:

I like the proposal in general, but the snake case feels decidedly un-Swifty (although I like snake case personally it isn't the Swift convention and I do like strong conventions).

Sent from my iPad

On Dec 5, 2015, at 7:46 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

I like "associated". Or maybe "withtype". Anything clear and without underscore.

protocol Foo {
associated T
}

protocol Foo {
withtype T
}

On Dec 5, 2015, at 5:43 PM, Stephen Celis via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 5, 2015, at 8:11 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

If we must keep this concept, I would prefer something without an underscore for the keyword, like "associatedtype" or perhaps "typeassociation"

Or merely "associated".
_______________________________________________
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

Great :)

Also, this hasn't been explicitly discussed yet. But do you all agree about adding "real" typealias declarations (with the typealias keyword) inside protocols?

Loïc

···

On Dec 6, 2015, at 3:20 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Sat, Dec 5, 2015 at 5:43 PM, Stephen Celis via swift-evolution > <swift-evolution@swift.org> wrote:

On Dec 5, 2015, at 8:11 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

If we must keep this concept, I would prefer something without an underscore for the keyword, like "associatedtype" or perhaps "typeassociation"

Or merely "associated".

+1 to the proposal, emphasizing the distinction is important; and I
like "associated" as the keyword for this purpose, too.

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

I have drafted a formal proposal here: Swift: Formal proposal to introduce new specific keyword for associated type declarations. · GitHub
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 :innocent: )

···

On Dec 6, 2015, at 1:48 AM, John McCall <rjmccall@apple.com> wrote:

On Dec 5, 2015, at 4:35 PM, Loïc Lecrenier via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Why not just „type“?

protocol Foo {
    type T
}

-Thorsten

···

Am 06.12.2015 um 02:46 schrieb Austin Zheng via swift-evolution <swift-evolution@swift.org>:

I like "associated". Or maybe "withtype". Anything clear and without underscore.

protocol Foo {
  associated T
}

protocol Foo {
withtype T
}

On Dec 5, 2015, at 5:43 PM, Stephen Celis via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 5, 2015, at 8:11 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

If we must keep this concept, I would prefer something without an underscore for the keyword, like "associatedtype" or perhaps "typeassociation"

Or merely "associated".
_______________________________________________
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

Concrete typealieases are not requirements, so they shouldn't be
defined inside of a protocol. Instead, they should be defined in the
protocol extension. In fact, this has been a plan of record for some
time, but it wasn't implemented.

extension SequenceType {
  typealias Element = Generator.Element
}

Dmitri

···

On Sat, Dec 5, 2015 at 6:27 PM, Loïc Lecrenier <loiclecrenier@icloud.com> wrote:

Great :)

Also, this hasn't been explicitly discussed yet. But do you all agree about adding "real" typealias declarations (with the typealias keyword) inside protocols?

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

However, if a protocol wished to use type aliases not as part of a contract but for clarity, this would still need to be defined within the protocol in order for the associated types to be used in the typealias declarations.

-DW

···

On Dec 5, 2015, at 7:29 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:

On Sat, Dec 5, 2015 at 6:27 PM, Loïc Lecrenier <loiclecrenier@icloud.com> wrote:

Great :)

Also, this hasn't been explicitly discussed yet. But do you all agree about adding "real" typealias declarations (with the typealias keyword) inside protocols?

Concrete typealieases are not requirements, so they shouldn't be
defined inside of a protocol. Instead, they should be defined in the
protocol extension. In fact, this has been a plan of record for some
time, but it wasn't implemented.

extension SequenceType {
typealias Element = Generator.Element
}

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

This makes sense. Thanks for the quick reply.

Loïc

···

On Dec 6, 2015, at 3:29 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Sat, Dec 5, 2015 at 6:27 PM, Loïc Lecrenier <loiclecrenier@icloud.com> wrote:
Great :)

Also, this hasn't been explicitly discussed yet. But do you all agree about adding "real" typealias declarations (with the typealias keyword) inside protocols?

Concrete typealieases are not requirements, so they shouldn't be
defined inside of a protocol. Instead, they should be defined in the
protocol extension. In fact, this has been a plan of record for some
time, but it wasn't implemented.

extension SequenceType {
typealias Element = Generator.Element
}

Dmitri

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

+1 for using a distinct keyword for associated types

···

On Sat, Dec 5, 2015 at 9:49 PM David Waite via swift-evolution < swift-evolution@swift.org> wrote:

However, if a protocol wished to use type aliases not as part of a
contract but for clarity, this would still need to be defined within the
protocol in order for the associated types to be used in the typealias
declarations.

-DW

> On Dec 5, 2015, at 7:29 PM, Dmitri Gribenko via swift-evolution < > swift-evolution@swift.org> wrote:
>
> On Sat, Dec 5, 2015 at 6:27 PM, Loïc Lecrenier <loiclecrenier@icloud.com> > wrote:
>> Great :)
>>
>> Also, this hasn't been explicitly discussed yet. But do you all agree
about adding "real" typealias declarations (with the typealias keyword)
inside protocols?
>
> Concrete typealieases are not requirements, so they shouldn't be
> defined inside of a protocol. Instead, they should be defined in the
> protocol extension. In fact, this has been a plan of record for some
> time, but it wasn't implemented.
>
> extension SequenceType {
> typealias Element = Generator.Element
> }
>
> Dmitri
>
> --
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/
> _______________________________________________
> 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

“type” feels more ambiguous to me with the existence of Foo.Type.

Stephen

···

On Dec 6, 2015, at 8:51 AM, Thorsten Seitz <thorsten.seitz@web.de> wrote:

Why not just „type“?

protocol Foo {
   type T
}

-Thorsten

Am 06.12.2015 um 02:46 schrieb Austin Zheng via swift-evolution <swift-evolution@swift.org>:

I like "associated". Or maybe "withtype". Anything clear and without underscore.

protocol Foo {
associated T
}

protocol Foo {
withtype T
}

On Dec 5, 2015, at 5:43 PM, Stephen Celis via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 5, 2015, at 8:11 PM, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> wrote:

If we must keep this concept, I would prefer something without an underscore for the keyword, like "associatedtype" or perhaps "typeassociation"

Or merely "associated".
_______________________________________________
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

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@icloud.com> wrote:

I have drafted a formal proposal here: Swift: Formal proposal to introduce new specific keyword for associated type declarations. · GitHub
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 :innocent: )

On Dec 6, 2015, at 1:48 AM, John McCall <rjmccall@apple.com> wrote:

On Dec 5, 2015, at 4:35 PM, Loïc Lecrenier via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@icloud.com> > wrote:
>
> I have drafted a formal proposal here:
Swift: Formal proposal to introduce new specific keyword for associated type declarations. · GitHub
> 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 :innocent: )
>
>> On Dec 6, 2015, at 1:48 AM, John McCall <rjmccall@apple.com> wrote:
>>
>>> On Dec 5, 2015, at 4:35 PM, Loïc Lecrenier via swift-evolution < > swift-evolution@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@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

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@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@swift.org <mailto:swift-evolution@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@icloud.com <mailto:loiclecrenier@icloud.com>> wrote:
>
> I have drafted a formal proposal here: Swift: Formal proposal to introduce new specific keyword for associated type declarations. · GitHub
> 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 :innocent: )
>
>> On Dec 6, 2015, at 1:48 AM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
>>
>>> On Dec 5, 2015, at 4:35 PM, Loïc Lecrenier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution