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

[Dave Abrahams]

> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution <swift-evolution at 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.

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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151222/bd3d3677/attachment.html>