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+sw...@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@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 <ja...@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_r...@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@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 >>> ja...@supmenow.com >>> +44 7523 279 698 >>> >> >> >> >> -- >> Wizard >> ja...@supmenow.com >> +44 7523 279 698 >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > -- Wizard ja...@supmenow.com +44 7523 279 698
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution