If part of this proposal is to update documentation to refer to it as "placeholder" typed then I am okay with "type"
On Wed, Dec 23, 2015 at 1:15 PM, Craig Cruden <[email protected]> wrote: > I prefer “type”. > > > On 2015-12-23, at 20:05:46, Pierre Monod-Broca via swift-evolution < > [email protected]> wrote: > > I would agree to stop talking about associated types and start talking > about placeholder types instead. > But as a keyword, IMO the problem is that `placeholder` is not appropriate > to define the implementation. > > eg > class Foo: Stream { > placeholder Payload = String // IMO doesn't feel right > type Payload = String // IMO feels good > } > > -- > Pierre > > Le 23 déc. 2015 à 13:59, James Campbell <[email protected]> a écrit : > > 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 < > [email protected]> 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 < >> [email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > > > -- > Wizard > [email protected] > +44 7523 279 698 > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > -- Wizard [email protected] +44 7523 279 698
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
