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

[Kelly Gerber]

Some time ago, I read an interview with Marin Odersky (created Scala). He said that a program will grow quadratically as the number of things you don’t know increase. I’m assuming that is why Swift protocols have associated types (abstract type members) instead of generic type parameters. Associated types have to have an implementation, so you know what they are.

At any rate, I think recycling “typealias” was mistake. I’m sure that a better term will be chosen.

> On Dec 19, 2015, at 8:48 PM, Jacob Bandes-Storch <jtbandes at gmail.com> wrote:
> 
> Am I too late to throw in more off-the-cuff suggestions?
> 
> protocol SequenceType {
>     having Generator
> }
> 
> protocol SequenceType<having Generator> { }   // in the protocol signature, but distinct from a generic param
> 
> protocol SequenceType<any Generator> // same idea
> 
> 
> Jacob Bandes-Storch
> 
> On Sat, Dec 19, 2015 at 8:37 PM, Kelly Gerber via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I believe Scala uses just “type” for abstract type members. Is that too short? If too short, then how about “typemember”? Or perhaps “abstracttype”?
> 
> -Kelly
> 
> > 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>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151219/6894e115/attachment.html>