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