Introduce "associated_type" keyword


(Lo茂c Lecrenier) #1

Hi everyone :slight_smile:

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 :confused:

Thanks,

Lo茂c


(John McCall) #2

Hi everyone :slight_smile:

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 :confused:

Thanks,

Lo茂c
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #3

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


(Austin Zheng) #4

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


(Dmitri Gribenko) #5

+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>*/


(Matthew Johnson) #6

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


(Kevin Lundberg) #7

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 :slight_smile:

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 :confused:

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


#8

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"


(Lo茂c Lecrenier) #9

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


(Lo茂c Lecrenier) #10

Great :slight_smile:

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>*/


(Lo茂c Lecrenier) #11

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 :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 :slight_smile:

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 :confused:

Thanks,

Lo茂c
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Thorsten Seitz) #12

Why not just 鈥瀟ype鈥?

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


(Dmitri Gribenko) #13

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 :slight_smile:

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>*/


(David Waite) #14

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 :slight_smile:

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


(Lo茂c Lecrenier) #15

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 :slight_smile:

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>*/


(Ilya Belenkiy) #16

+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 :slight_smile:
>>
>> 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


#17

鈥渢ype鈥 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 鈥瀟ype鈥?

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


(Lo茂c Lecrenier) #18

Well, I went ahead and created a pull request :slight_smile:

I also included a 鈥減roposed 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鈥檚 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: 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 :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 :slight_smile:

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 :confused:

Thanks,

Lo茂c
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Alex Lew) #19

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 :slight_smile:

I also included a 鈥減roposed 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鈥檚 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:
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 :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 :slight_smile:
>>>
>>> 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 :confused:
>>>
>>> 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


(Lo茂c Lecrenier) #20

Yes, I mean 鈥渄eprecate typealias鈥 only in the context of associated types. Will clarify, thanks :slight_smile:

As for forbidding the default behavior, I don鈥檛 think I鈥檓 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
鈥渁ssociated ___ = ___鈥 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 :slight_smile:

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 :slight_smile:

I also included a 鈥減roposed 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鈥檚 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: 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 :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 :slight_smile:
>>>
>>> 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 :confused:
>>>
>>> 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