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

[Ross O'Brien]

There's a problem here because associated types aren't the same as generics.

I've been looking this up a lot recently because I've been trying to create
a delegate protocol for a generic type. The GenericType<X> requires a
GenericTypeDelegate<X> and Swift 2 protocols just don't support those yet;
the best workaround of the moment seems to be a wrapper type which wraps
the delegate's functions in closures.

This is a different concept to associated types. I've seen a couple of
examples around; the one I'm remembering at the moment involves a protocol
for Animals requiring them to have an associated Food type. A Cow could
thus be defined as a type implementing the Animal protocol, with an
associated type of Grass; this would be very different to an Animal being a
generic type, and a Cow being (perhaps typealiased as) an Animal<Grass>.
With the associated type, the Cow is known to always eat Grass; with the
generic type, every function is written to handle all foodstuffs.

So, no, the two different syntaxes are required - but protocols with
generic parameters (is that the right term for e.g. Grass in
Animal<Grass>?) would be a good addition to the language.


On Wed, Dec 23, 2015 at 11:06 PM, James Campbell via swift-evolution <
swift-evolution at swift.org> wrote:

> If we made class, structs, protocols and functions use the same generics
> syntax then I think it would make it more consistent rather than arguing
> about which keyword to use. I am for-ever being tripped up by lack of
> generics in the language.
>
> class Array<T>
> {
> func first() -> T?
> }
>
> struct Node<Value>
> {
> var value: Value
> }
>
> Array<Int>()
> Node<Int>()
>
> or
>
> func makeACell<T>() -> T
> {
> }
>
> makeACell<MyCell>()
>
> or
>
> protocol Collection<Item>
> {
> func first() -> Item?
> }
>
> class IntBag : Collection<Int> //We bind protocol "associated type" using
> generic syntax when subclassing. In this case we are saying Item should be
> type Int
> {
> }
>
> class Array<Item>: Collection<Item> //We bind protocol "associated type"
> using generic syntax when subclassing. In this case we are saying Item
> should be the same type as the generic type for Array
> {
> }
>
> IntBag()
> Array<Int>()
>
>
> On Wed, Dec 23, 2015 at 10:58 PM, James Campbell <james at supmenow.com>
> wrote:
>
>> They are placeholders because in the protocol:
>>
>> prtocotol Collection
>> {
>>   placeholder Item
>>
>>   func first() -> Item?
>>  {
>>  }
>> }
>>
>> Item is a placeholder for a concrete type, at this moment this is a
>> concept "A collection should return an item of a type" but we don't know
>> what that type is as its a plaeholder for a type.
>>
>> therefore in:
>>
>> class IntCollection: Collection
>> {
>>    placeholder Item = Int
>> }
>>
>> We are saying that the placeholder should now become a concrete type. In
>> my eyes associated types are nothing more than generics for protocols which
>> in turn could be argued is some kind of placeholder.
>>
>> Associated type means nothing to me, associated to what ? A type could be
>> associated to many things like a variable, or a generic or whatever. A
>> placeholder to mean does what it says on the tin. If we moved to protocols
>> using a syntax closer to generics for classes then I think it would be
>> simpilar to grasp for beginners .
>>
>> On Wed, Dec 23, 2015 at 9:35 PM, Jordan Rose <jordan_rose at apple.com>
>> wrote:
>>
>>> James or Erica (or someone else), can you explain what makes these types
>>> "placeholders"? I don't think of the other requirements in a protocol as
>>> "placeholder properties" or "placeholder methods".
>>>
>>> My explanation of these things is "When a particular type X conforms to
>>> a protocol, you can ask about the types that X uses to implement the
>>> requirements of the protocol". I guess we could call them "related types"
>>> instead of "associated types", but that doesn't seem significantly
>>> different.
>>>
>>> Jordan
>>>
>>>
>>> > On Dec 23, 2015, at 12:42, James Campbell via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>> >
>>> > The thing is associated type means nothing to me, it's too technical.
>>> Placeholder type I think would be better even if it's only what we called
>>> it in the documentation
>>> >
>>> > Sent from my iPhone
>>>
>>>
>>
>>
>> --
>>  Wizard
>> james at supmenow.com
>> +44 7523 279 698
>>
>
>
>
> --
>  Wizard
> james at supmenow.com
> +44 7523 279 698
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151226/011b030a/attachment.html>