> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution
> <[email protected]> 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.
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
>
>
>> On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
-Dave
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
