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

Evolution Discussion
21

If I understand the Associated Types (I wouldn't be surprised if I have it
all wrong), don't they really define Types used as, in standard English,
"components", or "elements" of the protocol? If so, the problem is that the
words "component" and "element" are already used for other things.

···

On Sun, Dec 20, 2015 at 1:18 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:

> 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

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

22

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.

good point - maybe it's because I'm no native speaker, but for me "associated type" is just a technical term with no obvious meaning.

23

If part of this proposal is to update documentation to refer to it as
"placeholder" typed then I am okay with "type"

···

On Wed, Dec 23, 2015 at 1:15 PM, Craig Cruden <ccruden@novafore.com> wrote:

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

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

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

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

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

24

for me "associated type" is just a technical term with no obvious meaning.

That's not a bad thing. You get a hint that something funny is going on, and if you don't know what, you can look it up. You even have a great keyword to search for, right there.

Compared to that, something like “required type” doesn't tell you much about the gravity of the change. If you know about required constructors, you could assume that required types are like that — and they are like that, but they also change your protocol in a pretty spectacular way.

Anything is better than just “typealias”, though.

A.

25

Fair enough; "associated type" is a fairly vacuous term. I think the implication is that when you choose a model of the protocol, the concrete type, then these other types come along with it. But that's not immediately clear, so I don't think renaming the feature is out of the question.

I don't like the name "placeholder" or "placeholder type" because that only describes how they're used in the protocol. When you're actually implementing a generic function, the generic parameter is a sort of placeholder, and the associated types are just as concrete as the conforming type itself.

Jordan

···

On Dec 20, 2015, at 3:58 , Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

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.

good point - maybe it's because I'm no native speaker, but for me "associated type" is just a technical term with no obvious meaning.

26

You even have a great keyword to search for, right there.

Good point - we are lucky that Apple has so much influence to make "swift" already a useful search term so we don't have to look for "swiftlang" ;-)
Still undecided wether this argument is a bad justification for cryptic names in general...

27

I’m actually coming around to wanting it to be just “type” as a contextual keyword, if we can make that work. The point is that these types aren’t “associated” in any way that distinguishes them from other requirements on nested declarations, i.e. funcs and vars.

-Dave

···

On Dec 21, 2015, at 4:57 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 20, 2015, at 3:58 , Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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.

good point - maybe it's because I'm no native speaker, but for me "associated type" is just a technical term with no obvious meaning.

Fair enough; "associated type" is a fairly vacuous term. I think the implication is that when you choose a model of the protocol, the concrete type, then these other types come along with it. But that's not immediately clear, so I don't think renaming the feature is out of the question.

I don't like the name "placeholder" or "placeholder type" because that only describes how they're used in the protocol. When you're actually implementing a generic function, the generic parameter is a sort of placeholder, and the associated types are just as concrete as the conforming type itself.

28

Here's a word with meaning: parameter. Everything else I've seen sounds vague or approximate. Using the idea of a parameter would solidify the conceptual relationship between protocols-with-associated-types and generics.

protocol P {
  parameter T
}

Guillaume Lessard

···

On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

When you're actually implementing a generic function, the generic parameter is [snip]

29

Yeah, if we could make 'type' work I'd prefer that too. None of our other protocol requirement declarations specifically call out the fact that they're protocol requirements, so it feels a bit weird to use a name like 'associatedtype' or 'requiredsomething' that belabors the relationship between the protocol and the requirement.

-Joe

···

On Dec 21, 2015, at 6:34 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 21, 2015, at 4:57 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Dec 20, 2015, at 3:58 , Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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.

good point - maybe it's because I'm no native speaker, but for me "associated type" is just a technical term with no obvious meaning.

Fair enough; "associated type" is a fairly vacuous term. I think the implication is that when you choose a model of the protocol, the concrete type, then these other types come along with it. But that's not immediately clear, so I don't think renaming the feature is out of the question.

I don't like the name "placeholder" or "placeholder type" because that only describes how they're used in the protocol. When you're actually implementing a generic function, the generic parameter is a sort of placeholder, and the associated types are just as concrete as the conforming type itself.

I’m actually coming around to wanting it to be just “type” as a contextual keyword, if we can make that work. The point is that these types aren’t “associated” in any way that distinguishes them from other requirements on nested declarations, i.e. funcs and vars.

30

Could also use `typename`. But maybe that's too easy to mix with `typealias`.

···

Le 21 déc. 2015 à 21:34, Dave Abrahams via swift-evolution <swift-evolution@swift.org> a écrit :

I’m actually coming around to wanting it to be just “type” as a contextual keyword, if we can make that work. The point is that these types aren’t “associated” in any way that distinguishes them from other requirements on nested declarations, i.e. funcs and vars.

--
Michel Fortin
michel.fortin@michelf.ca
https://michelf.ca

31

As SE-0011 states, the concept of typealias is overloaded.
In one case, it's really just typedef.
In the other it's a stand-in for a deferred type that is specified by conforming classes.
While you could argue that the other typealias be redefined to typedef, it's pretty clear that in use, what's being described in the second case is an associated type. The word associated means related to or connected to, and type well it's a type. It basically says "this is a placeholder type that establishes a specific role in this protocol". I think associatedtype is a pretty good word to describe what a second-style typealias does: a conforming construct binds an associated type with an actual type instance.

The phrase "associated type" is used throughout the Swift Programming Language book, for example: "When defining a protocol, it is sometimes useful to declare one or more associated types as part of the protocol’s definition. An associated type gives a placeholder name (or alias) to a type that is used as part of the protocol. The actual type to use for that associated type is not specified until the protocol is adopted."

Some argue for raw type as the replacement:
Dave Abrahams writes, "I’m actually coming around to wanting it to be just “type” as a contextual keyword, if we can make that work. The point is that these types aren’t “associated” in any way that distinguishes them from other requirements on nested declarations, i.e. funcs and vars."
Joe Groff writes, "Yeah, if we could make 'type' work I'd prefer that too. None of our other protocol requirement declarations specifically call out the fact that they're protocol requirements, so it feels a bit weird to use a name like 'associatedtype' or 'requiredsomething' that belabors the relationship between the protocol and the requirement."
Type members are unlike the other kinds of required protocol members, like a property, method, initializer, or subscript requirement. They aren't implemented by a conforming construct or extension. They act as stand-in or placeholder: assigned not implemented. They can even be assigned as a default in the protocol definition, for example: typealias Generator : GeneratorType = IndexingGenerator<Self> in CollectionType.

Unless typestandin, typeplaceholder, or adoptedtype are placed on the table, I don't really see any reason to introduce a keyword other than associatedtype for this proposal.

-- E

···

On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org> wrote:

On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

When you're actually implementing a generic function, the generic parameter is [snip]

Here's a word with meaning: parameter. Everything else I've seen sounds vague or approximate. Using the idea of a parameter would solidify the conceptual relationship between protocols-with-associated-types and generics.

protocol P {
parameter T
}

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

32

“parameter” is a good thought. On it’s own it seems like it’s missing something though. But it gives me other ideas: “typeparam”, “type param", “typeparameter”, or “type parameter”.

Matt

···

On Dec 22, 2015, at 07:40, Guillaume Lessard via swift-evolution <swift-evolution@swift.org> wrote:

On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

When you're actually implementing a generic function, the generic parameter is [snip]

Here's a word with meaning: parameter. Everything else I've seen sounds vague or approximate. Using the idea of a parameter would solidify the conceptual relationship between protocols-with-associated-types and generics.

protocol P {
parameter T
}

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

33

How about 'deferred’? As in one of the following:

typealias MyType = deferred

or:
deferredtype MyType

or:
deferred typealias MyType

(apologies if this was already suggested previously)

···

On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

As SE-0011 states, the concept of typealias is overloaded.
In one case, it's really just typedef.
In the other it's a stand-in for a deferred type that is specified by conforming classes.
While you could argue that the other typealias be redefined to typedef, it's pretty clear that in use, what's being described in the second case is an associated type. The word associated means related to or connected to, and type well it's a type. It basically says "this is a placeholder type that establishes a specific role in this protocol". I think associatedtype is a pretty good word to describe what a second-style typealias does: a conforming construct binds an associated type with an actual type instance.

The phrase "associated type" is used throughout the Swift Programming Language book, for example: "When defining a protocol, it is sometimes useful to declare one or more associated types as part of the protocol’s definition. An associated type gives a placeholder name (or alias) to a type that is used as part of the protocol. The actual type to use for that associated type is not specified until the protocol is adopted."

Some argue for raw type as the replacement:
Dave Abrahams writes, "I’m actually coming around to wanting it to be just “type” as a contextual keyword, if we can make that work. The point is that these types aren’t “associated” in any way that distinguishes them from other requirements on nested declarations, i.e. funcs and vars."
Joe Groff writes, "Yeah, if we could make 'type' work I'd prefer that too. None of our other protocol requirement declarations specifically call out the fact that they're protocol requirements, so it feels a bit weird to use a name like 'associatedtype' or 'requiredsomething' that belabors the relationship between the protocol and the requirement."
Type members are unlike the other kinds of required protocol members, like a property, method, initializer, or subscript requirement. They aren't implemented by a conforming construct or extension. They act as stand-in or placeholder: assigned not implemented. They can even be assigned as a default in the protocol definition, for example: typealias Generator : GeneratorType = IndexingGenerator<Self> in CollectionType.

Unless typestandin, typeplaceholder, or adoptedtype are placed on the table, I don't really see any reason to introduce a keyword other than associatedtype for this proposal.

-- E

On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

When you're actually implementing a generic function, the generic parameter is [snip]

Here's a word with meaning: parameter. Everything else I've seen sounds vague or approximate. Using the idea of a parameter would solidify the conceptual relationship between protocols-with-associated-types and generics.

protocol P {
parameter T
}

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

34

As SE-0011 states, the concept of typealias is overloaded.
In one case, it's really just typedef.
In the other it's a stand-in for a deferred type that is specified by conforming classes.
While you could argue that the other typealias be redefined to typedef, it's pretty clear that in use, what's being described in the second case is an associated type. The word associated means related to or connected to, and type well it's a type. It basically says "this is a placeholder type that establishes a specific role in this protocol". I think associatedtype is a pretty good word to describe what a second-style typealias does: a conforming construct binds an associated type with an actual type instance.

The phrase "associated type" is used throughout the Swift Programming Language book, for example: "When defining a protocol, it is sometimes useful to declare one or more associated types as part of the protocol’s definition. An associated type gives a placeholder name (or alias) to a type that is used as part of the protocol. The actual type to use for that associated type is not specified until the protocol is adopted."

Some argue for raw type as the replacement:
Dave Abrahams writes, "I’m actually coming around to wanting it to be just “type” as a contextual keyword, if we can make that work. The point is that these types aren’t “associated” in any way that distinguishes them from other requirements on nested declarations, i.e. funcs and vars."
Joe Groff writes, "Yeah, if we could make 'type' work I'd prefer that too. None of our other protocol requirement declarations specifically call out the fact that they're protocol requirements, so it feels a bit weird to use a name like 'associatedtype' or 'requiredsomething' that belabors the relationship between the protocol and the requirement."
Type members are unlike the other kinds of required protocol members, like a property, method, initializer, or subscript requirement. They aren't implemented by a conforming construct or extension. They act as stand-in or placeholder: assigned not implemented. They can even be assigned as a default in the protocol definition, for example: typealias Generator : GeneratorType = IndexingGenerator<Self> in CollectionType.

Unless typestandin, typeplaceholder, or adoptedtype are placed on the table, I don't really see any reason to introduce a keyword other than associatedtype for this proposal.

+1. associatedtype seems better than any other option I’ve seen thus far (including the new ones you mentioned).

···

On Dec 22, 2015, at 11:30 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

-- E

On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

When you're actually implementing a generic function, the generic parameter is [snip]

Here's a word with meaning: parameter. Everything else I've seen sounds vague or approximate. Using the idea of a parameter would solidify the conceptual relationship between protocols-with-associated-types and generics.

protocol P {
parameter T
}

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

35

The fact that “associated type” is used throughout the documentation is worth making note of, but it could also be that some other replacement would make the concept more clear than it currently is in the documentation.

Matt

···

On Dec 22, 2015, at 09:30, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

The phrase "associated type" is used throughout the Swift Programming Language book, for example: "When defining a protocol, it is sometimes useful to declare one or more associated types as part of the protocol’s definition. An associated type gives a placeholder name (or alias) to a type that is used as part of the protocol. The actual type to use for that associated type is not specified until the protocol is adopted."

36

Agreed for requiredtype. But I am not convinced “associatedtype” belabors the relationship between the protocol and the requirements.

The word “associated” is never used as a replacement for “requirement”. It just names what the requirement is.
“[protocol] can only be used as a generic constraint because it has Self or __associated type requirements__”
“Grammar of a protocol __associated type__ declaration” (for comparison: “Grammar of a protocol __subscript__ declaration”)

(Counterpoint: maybe “associated” was only used there to avoid saying “type requirements/declaration”, which would be confusing)

I am now totally fine with “type”. But I am still afraid that it will be recycled elsewhere for a completely different purpose. Maybe that’s what you alluded to with “if we could make type work”?

Anyway, it’s the holidays, and I don’t want to bother people with work. I think I will modify the proposal with a link to this discussion instead of “Community Responses”, and we’ll have three days right after the holidays to make a final choice :-)

Loïc

PS: here is the result of a survey asking developers which keyword they prefer: https://www.surveymonkey.com/results/SM-7L7WMQ3J/
2 people (out of 100) chose “other” and specified “type”. Sadly it wasn’t presented as an option, sorry :(

···

On Dec 22, 2015, at 3:56 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Yeah, if we could make 'type' work I'd prefer that too. None of our other protocol requirement declarations specifically call out the fact that they're protocol requirements, so it feels a bit weird to use a name like 'associatedtype' or 'requiredsomething' that belabors the relationship between the protocol and the requirement.

-Joe

37

As SE-0011 states, the concept of typealias is overloaded.
In one case, it's really just typedef.
In the other it's a stand-in for a deferred type that is specified by conforming classes.
While you could argue that the other typealias be redefined to typedef, it's pretty clear that in use, what's being described in the second case is an associated type. The word associated means related to or connected to, and type well it's a type. It basically says "this is a placeholder type that establishes a specific role in this protocol". I think associatedtype is a pretty good word to describe what a second-style typealias does: a conforming construct binds an associated type with an actual type instance.

The phrase "associated type" is used throughout the Swift Programming Language book, for example: "When defining a protocol, it is sometimes useful to declare one or more associated types as part of the protocol’s definition. An associated type gives a placeholder name (or alias) to a type that is used as part of the protocol. The actual type to use for that associated type is not specified until the protocol is adopted."

Some argue for raw type as the replacement:
Dave Abrahams writes, "I’m actually coming around to wanting it to be just “type” as a contextual keyword, if we can make that work. The point is that these types aren’t “associated” in any way that distinguishes them from other requirements on nested declarations, i.e. funcs and vars."
Joe Groff writes, "Yeah, if we could make 'type' work I'd prefer that too. None of our other protocol requirement declarations specifically call out the fact that they're protocol requirements, so it feels a bit weird to use a name like 'associatedtype' or 'requiredsomething' that belabors the relationship between the protocol and the requirement."
Type members are unlike the other kinds of required protocol members, like a property, method, initializer, or subscript requirement. They aren't implemented by a conforming construct or extension.

I don’t see how this:

protocol P {
  type/*alias*/ A
}

struct X : P {
  struct A {}
}

is fundamentally any different from:

protocol P {
  func f()
}

struct X : P {
  func f() {}
}

What am I missing?

They act as stand-in or placeholder: assigned not implemented. They can even be assigned as a default in the protocol definition, for example: typealias Generator : GeneratorType = IndexingGenerator<Self> in CollectionType.

The way defaults are specified is a non-uniformity that we want to fix. There’s no reason we couldn’t be providing default implementations of required protocol methods in the protocol body either.

Unless typestandin, typeplaceholder, or adoptedtype are placed on the table, I don't really see any reason to introduce a keyword other than associatedtype for this proposal.

-- E

When you're actually implementing a generic function, the generic parameter is [snip]

Here's a word with meaning: parameter. Everything else I've seen sounds vague or approximate. Using the idea of a parameter would solidify the conceptual relationship between protocols-with-associated-types and generics.

protocol P {
parameter T
}

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

-Dave

···

On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

38

It’s not a parameter, though, because it does not vary the way a parameter does: a given type X cannot conform to a protocol with two different bindings for a given associated type.

  - Doug

···

On Dec 22, 2015, at 11:05 AM, Matt Whiteside via swift-evolution <swift-evolution@swift.org> wrote:

“parameter” is a good thought. On it’s own it seems like it’s missing something though. But it gives me other ideas: “typeparam”, “type param", “typeparameter”, or “type parameter”.

39

I still prefer "type" as "associatedtype" is quite a mouthful and, really being two words, quite untypical for a keyword.

And required functions etc. use simply "func" instead of "requiredfunc" as well.

-Thorsten

···

Am 22.12.2015 um 18:30 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:

As SE-0011 states, the concept of typealias is overloaded.
In one case, it's really just typedef.
In the other it's a stand-in for a deferred type that is specified by conforming classes.
While you could argue that the other typealias be redefined to typedef, it's pretty clear that in use, what's being described in the second case is an associated type. The word associated means related to or connected to, and type well it's a type. It basically says "this is a placeholder type that establishes a specific role in this protocol". I think associatedtype is a pretty good word to describe what a second-style typealias does: a conforming construct binds an associated type with an actual type instance.

The phrase "associated type" is used throughout the Swift Programming Language book, for example: "When defining a protocol, it is sometimes useful to declare one or more associated types as part of the protocol’s definition. An associated type gives a placeholder name (or alias) to a type that is used as part of the protocol. The actual type to use for that associated type is not specified until the protocol is adopted."

Some argue for raw type as the replacement:
Dave Abrahams writes, "I’m actually coming around to wanting it to be just “type” as a contextual keyword, if we can make that work. The point is that these types aren’t “associated” in any way that distinguishes them from other requirements on nested declarations, i.e. funcs and vars."
Joe Groff writes, "Yeah, if we could make 'type' work I'd prefer that too. None of our other protocol requirement declarations specifically call out the fact that they're protocol requirements, so it feels a bit weird to use a name like 'associatedtype' or 'requiredsomething' that belabors the relationship between the protocol and the requirement."
Type members are unlike the other kinds of required protocol members, like a property, method, initializer, or subscript requirement. They aren't implemented by a conforming construct or extension. They act as stand-in or placeholder: assigned not implemented. They can even be assigned as a default in the protocol definition, for example: typealias Generator : GeneratorType = IndexingGenerator<Self> in CollectionType.

Unless typestandin, typeplaceholder, or adoptedtype are placed on the table, I don't really see any reason to introduce a keyword other than associatedtype for this proposal.

-- E

On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org> wrote:

On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

When you're actually implementing a generic function, the generic parameter is [snip]

Here's a word with meaning: parameter. Everything else I've seen sounds vague or approximate. Using the idea of a parameter would solidify the conceptual relationship between protocols-with-associated-types and generics.

protocol P {
parameter T
}

Guillaume Lessard
_______________________________________________
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

40

Unless typestandin, typeplaceholder, or adoptedtype are placed on the table, I don't really see any reason to introduce a keyword other than associatedtype for this proposal.

+1. associatedtype seems better than any other option I’ve seen thus far (including the new ones you mentioned).

If the language construct is called an “associated type,” then introducing a keyword that uses any terminology other than “associated” is a recipe for eternal community confusion.

I could go for associatedtype, associated_type, or associated — but I agree that anything else, including typealias, seems inferior.

P