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

[James Campbell]

What about templatetype ? This could also work if we started referring
generics as Templates :) and extended them to protocols and functions.


On Sat, Dec 26, 2015 at 3:15 PM, Ross O'Brien <narrativium+swift at gmail.com>
wrote:

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


-- 
 Wizard
james at supmenow.com
+44 7523 279 698
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151226/842847be/attachment.html>