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 < [email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 < >>> [email protected]> 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 >> [email protected] >> +44 7523 279 698 >> > > > > -- > Wizard > [email protected] > +44 7523 279 698 > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
