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

I believe Scala uses just “type” for abstract type members. Is that too short? If too short, then how about “typemember”? Or perhaps “abstractype”?

-Kelly

···

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? :grin: (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

Am I too late to throw in more off-the-cuff suggestions?

protocol SequenceType {
    having Generator
}

protocol SequenceType<having Generator> { } // in the protocol signature,
but distinct from a generic param

protocol SequenceType<any Generator> // same idea

Jacob Bandes-Storch

···

On Sat, Dec 19, 2015 at 8:37 PM, Kelly Gerber via swift-evolution < swift-evolution@swift.org> wrote:

I believe Scala uses just “type” for abstract type members. Is that too
short? If too short, then how about “typemember”? Or perhaps “abstractype”?

-Kelly

> 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? :grin: (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

Some time ago, I read an interview with Marin Odersky (created Scala). He said that a program will grow quadratically as the number of things you don’t know increase. I’m assuming that is why Swift protocols have associated types (abstract type members) instead of generic type parameters. Associated types have to have an implementation, so you know what they are.

At any rate, I think recycling “typealias” was mistake. I’m sure that a better term will be chosen.

···

On Dec 19, 2015, at 8:48 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

Am I too late to throw in more off-the-cuff suggestions?

protocol SequenceType {
    having Generator
}

protocol SequenceType<having Generator> { } // in the protocol signature, but distinct from a generic param

protocol SequenceType<any Generator> // same idea

Jacob Bandes-Storch

On Sat, Dec 19, 2015 at 8:37 PM, Kelly Gerber via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I believe Scala uses just “type” for abstract type members. Is that too short? If too short, then how about “typemember”? Or perhaps “abstracttype”?

-Kelly

> 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? :grin: (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