I think we should use "placeholder" it more accurately describes what it does. For a bigger change then I would propose my protocol generics idea.
On Wed, Dec 23, 2015 at 12:50 PM, Pierre Monod-Broca via swift-evolution < swift-evolution@swift.org> wrote: > +1 for `type`, it is consistent with `func`, `var` and `init`. It looks > good to me. > > eg: > > protocol Stream { > type Payload > var ready: Bool { get } > func read() -> Payload? > } > > protocol Collection { > type Element > var count: Int { get } > func contains(element: Element) -> Bool > } > > > -- > Pierre > > Le 19 déc. 2015 à 18:46, Loïc Lecrenier via swift-evolution < > swift-evolution@swift.org> a écrit : > > Hi, > > I’m starting a new thread for this proposal > https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md > > So far, everybody agreed that using distinct keywords for type alias and > associated type declarations is a good idea. > However, some people think that “associated” is not an ideal replacement > because it is too vague. > I would like to choose a better keyword before the review, but I’m > struggling to find a good replacement. > > So, here are some keywords that were proposed by the community. > > 1. associated_type > This is the original proposed keyword. It is extremely clear, but > snake_cases are un-Swifty. > > 2. associatedtype (or typeassociation) > This was the first alternative to associated_type. Its purpose is still > extremely clear. > I like it a lot, but it is a bit long and difficult to read. > > 3. associated > This is the keyword I chose for the proposal because it was the most > well-received initially. > It is quite short, very different from “typealias", and sounds good. > However, it is also vaguer. > Because the word “type” is not in it, it’s unclear what should follow it, > and it’s unclear what it declares. > For example, one could think that it is an associated *value* and write > protocol FixedSizeCollectionProtocol { > associated size : Int > } > Although honestly I doubt many people would write that. > > 4. withtype (or needstype) > It is short, somewhat easy to read, has the word “type” in it, and some > concept of association thanks to “with”. I like it. > But it doesn’t sound very good, and is still vaguer than “associatedtype”. > > 5. type > This keyword was proposed by several people, but I strongly dislike it. > It conflicts with an other proposal about unifying the “static” and > “class” keywords for type-level members. > I think the fact that it was proposed for two completely different > purposes shows that it is too abstract. > It would make searching for help more difficult because of its bad > googleability. > > > Personally, I would like to either keep “associated”, or use > “associatedtype” because they are the most obvious choices. > > 1) Do you agree about using “associatedtype”? > 2) If not, which keyword would you prefer to use? why? (you can introduce > a new one) > Bonus) Maybe some twitter-famous person could make a quick poll and see > which one developers prefer? 😁 (after they read this email) > I would gladly do it myself, but I don’t think my twenty (mostly fake) > followers will give me a lot of information. > > Loïc > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > 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