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] <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

Reply via email to