[swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Craig Cruden]

I prefer “type”.


> On 2015-12-23, at 20:05:46, Pierre Monod-Broca via swift-evolution <swift-evolution at swift.org> 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 <james at supmenow.com <mailto:james at supmenow.com>> 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 <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 <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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> 
>> 
>> -- 
>>  Wizard
>> james at supmenow.com <mailto:james at supmenow.com>
>> +44 7523 279 698
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/9f2a288b/attachment.html>