[SE-0011] Re-considering the replacement keyword for "typealias"

Loic_Lecrenier · December 19, 2015, 5:46pm

Hi,

I’m starting a new thread for this proposal swift-evolution/0011-replace-typealias-associated.md at master · apple/swift-evolution · GitHub

So far, everybody agreed that using distinct keywords for type alias and associated type declarations is a good idea.
However, some people think that “associated” is not an ideal replacement because it is too vague.
I would like to choose a better keyword before the review, but I’m struggling to find a good replacement.

So, here are some keywords that were proposed by the community.

1. associated_type
This is the original proposed keyword. It is extremely clear, but snake_cases are un-Swifty.

2. associatedtype (or typeassociation)
This was the first alternative to associated_type. Its purpose is still extremely clear.
I like it a lot, but it is a bit long and difficult to read.

3. associated
This is the keyword I chose for the proposal because it was the most well-received initially.
It is quite short, very different from “typealias", and sounds good. However, it is also vaguer.
Because the word “type” is not in it, it’s unclear what should follow it, and it’s unclear what it declares.
For example, one could think that it is an associated *value* and write
protocol FixedSizeCollectionProtocol {
associated size : Int
}
Although honestly I doubt many people would write that.

4. withtype (or needstype)
It is short, somewhat easy to read, has the word “type” in it, and some concept of association thanks to “with”. I like it.
But it doesn’t sound very good, and is still vaguer than “associatedtype”.

5. type
This keyword was proposed by several people, but I strongly dislike it.
It conflicts with an other proposal about unifying the “static” and “class” keywords for type-level members.
I think the fact that it was proposed for two completely different purposes shows that it is too abstract.
It would make searching for help more difficult because of its bad googleability.

Personally, I would like to either keep “associated”, or use “associatedtype” because they are the most obvious choices.

1) Do you agree about using “associatedtype”?
2) If not, which keyword would you prefer to use? why? (you can introduce a new one)
Bonus) Maybe some twitter-famous person could make a quick poll and see which one developers prefer? (after they read this email)
I would gladly do it myself, but I don’t think my twenty (mostly fake) followers will give me a lot of information.

Loïc

Erica_Sadun · December 20, 2015, 1:21am

Maybe [some person] could make a quick poll and see which one developers prefer? (after they read this email)

Ask. Receive.

https://www.surveymonkey.com/r/S8F59XF

Tino · December 19, 2015, 6:07pm

snake_cases are un-Swifty

amen.

My first thought for a name was "placeholder", and I just saw that this was used in the description of the concept as well… so maybe this would be an option?

Tino

Janosch_Hildebrand · December 19, 2015, 6:09pm

1) Do you agree about using “associatedtype”?

I would be fine with either "associatedtype", "typeassociation" or "associated" but "associatedtype" is my favorite.

2) If not, which keyword would you prefer to use? why? (you can introduce a new one)

Not sure if that has been proposed before but "assoctype" might be another option that still includes the word "type" but is a bit shorter.
But personally I'd prefer "associatedtype" since it's clearer and it's not a keyword that is used often enough for the shortening to be worth it.

- Janosch

···

On 19 Dec 2015, at 18:46, Loïc Lecrenier via swift-evolution <swift-evolution@swift.org> wrote:

Tino · December 19, 2015, 10:52pm

Another spontaneous idea (not sure weather I actually like it — take it as brainstorming):
Variable deklarations have the form
thatIsTheName: ThatIsWhatIAm
so the ambiguity could be resolved by
ElementType: typealias
which would say "ElementType is a associated type", like
let i: Int
says "i is an integer"

Andrey_Tarantsov · December 20, 2015, 11:21am

Aren't we bikeshedding here? These are all good names; I think we can pick one, and leave the final choice to the core team.

My personal preference is for something like “associated type X” or “associated typealias X” — no need for an underscore when you can require a space. Right now “typealias” is probably the word to use, although if Swift later introduces “type”, that would be a better choice. And I see “associated” as a context-specific modifier anyway; could even be spelled “@associated” (I'm still unclear about the rules about @/no-@).

A.

pierremb · December 23, 2015, 12:50pm

+1 for `type`, it is consistent with `func`, `var` and `init`. It looks good to me.

eg:

protocol Stream {
    type Payload
    var ready: Bool { get }
    func read() -> Payload?
}

protocol Collection {
    type Element
    var count: Int { get }
    func contains(element: Element) -> Bool
}

···

--
Pierre

Le 19 déc. 2015 à 18:46, Loïc Lecrenier via swift-evolution <swift-evolution@swift.org> a écrit :

Hi,

I’m starting a new thread for this proposal https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

So far, everybody agreed that using distinct keywords for type alias and associated type declarations is a good idea.
However, some people think that “associated” is not an ideal replacement because it is too vague.
I would like to choose a better keyword before the review, but I’m struggling to find a good replacement.

So, here are some keywords that were proposed by the community.

1. associated_type
This is the original proposed keyword. It is extremely clear, but snake_cases are un-Swifty.

2. associatedtype (or typeassociation)
This was the first alternative to associated_type. Its purpose is still extremely clear.
I like it a lot, but it is a bit long and difficult to read.

3. associated
This is the keyword I chose for the proposal because it was the most well-received initially.
It is quite short, very different from “typealias", and sounds good. However, it is also vaguer.
Because the word “type” is not in it, it’s unclear what should follow it, and it’s unclear what it declares.
For example, one could think that it is an associated *value* and write
protocol FixedSizeCollectionProtocol {
associated size : Int
}
Although honestly I doubt many people would write that.

4. withtype (or needstype)
It is short, somewhat easy to read, has the word “type” in it, and some concept of association thanks to “with”. I like it.
But it doesn’t sound very good, and is still vaguer than “associatedtype”.

5. type
This keyword was proposed by several people, but I strongly dislike it.
It conflicts with an other proposal about unifying the “static” and “class” keywords for type-level members.
I think the fact that it was proposed for two completely different purposes shows that it is too abstract.
It would make searching for help more difficult because of its bad googleability.

Personally, I would like to either keep “associated”, or use “associatedtype” because they are the most obvious choices.

1) Do you agree about using “associatedtype”?
2) If not, which keyword would you prefer to use? why? (you can introduce a new one)
Bonus) Maybe some twitter-famous person could make a quick poll and see which one developers prefer? (after they read this email)
I would gladly do it myself, but I don’t think my twenty (mostly fake) followers will give me a lot of information.

Loïc

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

michelf · December 23, 2015, 9:53pm

inferredtype

···

--
Michel Fortin
https://michelf.ca

Andrew_Hoos · December 20, 2015, 9:06am

I second placeholder as the most rational keyword. Every description of the distinct usage of type alias refers to is a placeholder type. placeholder is one word(circumventingCase_issues) and is more descriptive of what it is than associated*. Seems like an easy win. Is there a some reason I am missing why *type* or associated* are better keyword fits?

Andrew Hoos

···

On Dec 19, 2015, at 10:07, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

snake_cases are un-Swifty

amen.

My first thought for a name was "placeholder", and I just saw that this was used in the description of the concept as well… so maybe this would be an option?

Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Loic_Lecrenier · December 20, 2015, 10:54am

-1
I understand the idea. But we would still need a replacement for “typealias” because “Element: typealias” says “Element is a type alias” and not “Element is an associated type”.
Also, it would be difficult to add inheritance clauses and default values.
“Element is an associated type that conforms to SequenceType, and is an Array of Int by default”
is currently
typealias Element : SequenceType = Array<Int>
but I don’t see how it could be written with your proposed syntax.

- Loïc

···

On Dec 19, 2015, at 11:52 PM, Tino Heth <2th@gmx.de> wrote:

Another spontaneous idea (not sure weather I actually like it — take it as brainstorming):
Variable deklarations have the form
thatIsTheName: ThatIsWhatIAm
so the ambiguity could be resolved by
ElementType: typealias
which would say "ElementType is a associated type", like
let i: Int
says "i is an integer"

Loic_Lecrenier · December 20, 2015, 11:47am

Aren't we bikeshedding here? These are all good names; I think we can pick one, and leave the final choice to the core team.

Yes, we are :(
I was reluctant to start this thread, but I think it’s worse if the core team has this debate during the review.
I promise I’ll choose a keyword before the end of the week (and it will most likely be requiredtype)

Loïc

···

My personal preference is for something like “associated type X” or “associated typealias X” — no need for an underscore when you can require a space. Right now “typealias” is probably the word to use, although if Swift later introduces “type”, that would be a better choice. And I see “associated” as a context-specific modifier anyway; could even be spelled “@associated” (I'm still unclear about the rules about @/no-@).

A.

James_Campbell · December 23, 2015, 12:59pm

I think we should use "placeholder" it more accurately describes what it
does. For a bigger change then I would propose my protocol generics idea.

···

On Wed, Dec 23, 2015 at 12:50 PM, Pierre Monod-Broca via swift-evolution < swift-evolution@swift.org> wrote:

+1 for `type`, it is consistent with `func`, `var` and `init`. It looks
good to me.

eg:

protocol Stream {
    type Payload
    var ready: Bool { get }
    func read() -> Payload?
}

protocol Collection {
    type Element
    var count: Int { get }
    func contains(element: Element) -> Bool
}

--
Pierre

Le 19 déc. 2015 à 18:46, Loïc Lecrenier via swift-evolution < > swift-evolution@swift.org> a écrit :

Hi,

I’m starting a new thread for this proposal
https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

So far, everybody agreed that using distinct keywords for type alias and
associated type declarations is a good idea.
However, some people think that “associated” is not an ideal replacement
because it is too vague.
I would like to choose a better keyword before the review, but I’m
struggling to find a good replacement.

So, here are some keywords that were proposed by the community.

1. associated_type
This is the original proposed keyword. It is extremely clear, but
snake_cases are un-Swifty.

2. associatedtype (or typeassociation)
This was the first alternative to associated_type. Its purpose is still
extremely clear.
I like it a lot, but it is a bit long and difficult to read.

3. associated
This is the keyword I chose for the proposal because it was the most
well-received initially.
It is quite short, very different from “typealias", and sounds good.
However, it is also vaguer.
Because the word “type” is not in it, it’s unclear what should follow it,
and it’s unclear what it declares.
For example, one could think that it is an associated *value* and write
protocol FixedSizeCollectionProtocol {
associated size : Int
}
Although honestly I doubt many people would write that.

4. withtype (or needstype)
It is short, somewhat easy to read, has the word “type” in it, and some
concept of association thanks to “with”. I like it.
But it doesn’t sound very good, and is still vaguer than “associatedtype”.

5. type
This keyword was proposed by several people, but I strongly dislike it.
It conflicts with an other proposal about unifying the “static” and
“class” keywords for type-level members.
I think the fact that it was proposed for two completely different
purposes shows that it is too abstract.
It would make searching for help more difficult because of its bad
googleability.

Personally, I would like to either keep “associated”, or use
“associatedtype” because they are the most obvious choices.

1) Do you agree about using “associatedtype”?
2) If not, which keyword would you prefer to use? why? (you can introduce
a new one)
Bonus) Maybe some twitter-famous person could make a quick poll and see
which one developers prefer? (after they read this email)
I would gladly do it myself, but I don’t think my twenty (mostly fake)
followers will give me a lot of information.

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

--
 Wizard
james@supmenow.com
+44 7523 279 698

pierremb · December 23, 2015, 1:05pm

I would agree to stop talking about associated types and start talking about placeholder types instead.
But as a keyword, IMO the problem is that `placeholder` is not appropriate to define the implementation.

eg
class Foo: Stream {
placeholder Payload = String // IMO doesn't feel right
type Payload = String // IMO feels good
}

···

--
Pierre

Le 23 déc. 2015 à 13:59, James Campbell <james@supmenow.com> a écrit :

I think we should use "placeholder" it more accurately describes what it does. For a bigger change then I would propose my protocol generics idea.

On Wed, Dec 23, 2015 at 12:50 PM, Pierre Monod-Broca via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 for `type`, it is consistent with `func`, `var` and `init`. It looks good to me.

eg:

protocol Stream {
    type Payload
    var ready: Bool { get }
    func read() -> Payload?
}

protocol Collection {
    type Element
    var count: Int { get }
    func contains(element: Element) -> Bool
}

--
Pierre

Le 19 déc. 2015 à 18:46, Loïc Lecrenier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Hi,

I’m starting a new thread for this proposal https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

So far, everybody agreed that using distinct keywords for type alias and associated type declarations is a good idea.
However, some people think that “associated” is not an ideal replacement because it is too vague.
I would like to choose a better keyword before the review, but I’m struggling to find a good replacement.

So, here are some keywords that were proposed by the community.

1. associated_type
This is the original proposed keyword. It is extremely clear, but snake_cases are un-Swifty.

2. associatedtype (or typeassociation)
This was the first alternative to associated_type. Its purpose is still extremely clear.
I like it a lot, but it is a bit long and difficult to read.

3. associated
This is the keyword I chose for the proposal because it was the most well-received initially.
It is quite short, very different from “typealias", and sounds good. However, it is also vaguer.
Because the word “type” is not in it, it’s unclear what should follow it, and it’s unclear what it declares.
For example, one could think that it is an associated *value* and write
protocol FixedSizeCollectionProtocol {
  associated size : Int
}
Although honestly I doubt many people would write that.

4. withtype (or needstype)
It is short, somewhat easy to read, has the word “type” in it, and some concept of association thanks to “with”. I like it.
But it doesn’t sound very good, and is still vaguer than “associatedtype”.

5. type
This keyword was proposed by several people, but I strongly dislike it.
It conflicts with an other proposal about unifying the “static” and “class” keywords for type-level members.
I think the fact that it was proposed for two completely different purposes shows that it is too abstract.
It would make searching for help more difficult because of its bad googleability.

Personally, I would like to either keep “associated”, or use “associatedtype” because they are the most obvious choices.

1) Do you agree about using “associatedtype”?
2) If not, which keyword would you prefer to use? why? (you can introduce a new one)
Bonus) Maybe some twitter-famous person could make a quick poll and see which one developers prefer? (after they read this email)
I would gladly do it myself, but I don’t think my twenty (mostly fake) followers will give me a lot of information.

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

--
 Wizard
james@supmenow.com <mailto:james@supmenow.com>
+44 7523 279 698

Douglas_Gregor · December 23, 2015, 10:30pm

It’s not always inferred, though.

- Doug

···

On Dec 23, 2015, at 1:53 PM, Michel Fortin via swift-evolution <swift-evolution@swift.org> wrote:

inferredtype

mwhiteside.dev · December 23, 2015, 10:51pm

Just want to put 2 other ideas out there for completeness:

`relatedtype`

`componenttype`

···

On Dec 23, 2015, at 14:30, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 23, 2015, at 1:53 PM, Michel Fortin via swift-evolution <swift-evolution@swift.org> wrote:

inferredtype

It’s not always inferred, though.

- Doug

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

dabrahams · December 23, 2015, 11:08pm

Just want to put 2 other ideas out there for completeness:

`relatedtype`

`componenttype`

My 2c: if we’re tack something onto “type”, the only appropriate modifier is “associated.” “Associated type” isn’t a term we invented; it’s the correct accepted technical term for the role these declarations play in generic programming.

inferredtype

It’s not always inferred, though.

- Doug

_______________________________________________
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

-Dave

···

On Dec 23, 2015, at 2:51 PM, Matt Whiteside via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 23, 2015, at 14:30, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 23, 2015, at 1:53 PM, Michel Fortin via swift-evolution <swift-evolution@swift.org> wrote:

Douglas_Gregor · December 23, 2015, 11:09pm

Agreed.

- Doug

···

On Dec 23, 2015, at 3:08 PM, Dave Abrahams <dabrahams@apple.com> wrote:

On Dec 23, 2015, at 2:51 PM, Matt Whiteside via swift-evolution <swift-evolution@swift.org> wrote:

Just want to put 2 other ideas out there for completeness:

`relatedtype`

`componenttype`

My 2c: if we’re tack something onto “type”, the only appropriate modifier is “associated.” “Associated type” isn’t a term we invented; it’s the correct accepted technical term for the role these declarations play in generic programming.

Brent_Royal-Gordon · December 20, 2015, 9:18am

Is there a some reason I am missing why *type* or associated* are better keyword fits?

The main reason to use `associated` is because the feature is called an "associated type". If we're willing to rename the feature to "placeholder type", then `placeholder` would be a good keyword.

···

--
Brent Royal-Gordon
Architechies

Loic_Lecrenier · December 20, 2015, 11:08am

I like placeholder too.
However, it also suffers from the lack of “type” in it.

So, the real comparison is between:
placeholder — associated
placholdertype — associatedtype

···

On Dec 20, 2015, at 10:06 AM, Andrew Hoos <andrewjhoos@gmail.com> wrote:

I second placeholder as the most rational keyword. Every description of the distinct usage of type alias refers to is a placeholder type. placeholder is one word(circumventingCase_issues) and is more descriptive of what it is than associated*. Seems like an easy win. Is there a some reason I am missing why *type* or associated* are better keyword fits?

Andrew Hoos

On Dec 19, 2015, at 10:07, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

snake_cases are un-Swifty

amen.

My first thought for a name was "placeholder", and I just saw that this was used in the description of the concept as well… so maybe this would be an option?

Tino
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Craig_Cruden · December 23, 2015, 1:15pm

I prefer “type”.

···

On 2015-12-23, at 20:05:46, Pierre Monod-Broca via swift-evolution <swift-evolution@swift.org> wrote:

I would agree to stop talking about associated types and start talking about placeholder types instead.
But as a keyword, IMO the problem is that `placeholder` is not appropriate to define the implementation.

eg
class Foo: Stream {
    placeholder Payload = String // IMO doesn't feel right
    type Payload = String // IMO feels good
}

--
Pierre

Le 23 déc. 2015 à 13:59, James Campbell <james@supmenow.com <mailto:james@supmenow.com>> a écrit :

I think we should use "placeholder" it more accurately describes what it does. For a bigger change then I would propose my protocol generics idea.

On Wed, Dec 23, 2015 at 12:50 PM, Pierre Monod-Broca via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1 for `type`, it is consistent with `func`, `var` and `init`. It looks good to me.

eg:

protocol Stream {
    type Payload
    var ready: Bool { get }
    func read() -> Payload?
}

protocol Collection {
    type Element
    var count: Int { get }
    func contains(element: Element) -> Bool
}

--
Pierre

Le 19 déc. 2015 à 18:46, Loïc Lecrenier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Hi,

I’m starting a new thread for this proposal https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

So far, everybody agreed that using distinct keywords for type alias and associated type declarations is a good idea.
However, some people think that “associated” is not an ideal replacement because it is too vague.
I would like to choose a better keyword before the review, but I’m struggling to find a good replacement.

So, here are some keywords that were proposed by the community.

1. associated_type
This is the original proposed keyword. It is extremely clear, but snake_cases are un-Swifty.

2. associatedtype (or typeassociation)
This was the first alternative to associated_type. Its purpose is still extremely clear.
I like it a lot, but it is a bit long and difficult to read.

3. associated
This is the keyword I chose for the proposal because it was the most well-received initially.
It is quite short, very different from “typealias", and sounds good. However, it is also vaguer.
Because the word “type” is not in it, it’s unclear what should follow it, and it’s unclear what it declares.
For example, one could think that it is an associated *value* and write
protocol FixedSizeCollectionProtocol {
  associated size : Int
}
Although honestly I doubt many people would write that.

4. withtype (or needstype)
It is short, somewhat easy to read, has the word “type” in it, and some concept of association thanks to “with”. I like it.
But it doesn’t sound very good, and is still vaguer than “associatedtype”.

5. type
This keyword was proposed by several people, but I strongly dislike it.
It conflicts with an other proposal about unifying the “static” and “class” keywords for type-level members.
I think the fact that it was proposed for two completely different purposes shows that it is too abstract.
It would make searching for help more difficult because of its bad googleability.

Personally, I would like to either keep “associated”, or use “associatedtype” because they are the most obvious choices.

1) Do you agree about using “associatedtype”?
2) If not, which keyword would you prefer to use? why? (you can introduce a new one)
Bonus) Maybe some twitter-famous person could make a quick poll and see which one developers prefer? (after they read this email)
I would gladly do it myself, but I don’t think my twenty (mostly fake) followers will give me a lot of information.

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

--
 Wizard
james@supmenow.com <mailto:james@supmenow.com>
+44 7523 279 698

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