I'm sure we're just bikeshedding at this point, but... I find "typealias" and "fallthrough" much easier to read, and easier to write, than "associatedtype". Upon further in(tro)spection, I think I'm reading typealias and fallthrough as compound words <https://en.wikipedia.org/wiki/English_compound>, rather than multiple words with no separation, so there is no question that they should be all-lowercase.
I find associatedtype harder to interpret as a compound word, so I'd expect some separation, either associated_type or associatedType. (I put some other suggestions that I like better in my previous email, though.) Jacob On Wed, Jan 6, 2016 at 12:56 PM, Loïc Lecrenier <swift-evolution@swift.org> wrote: > > > > What about the all lower case “associatedtype”? The underscore > alternative of “associated_type” breaks existing language precedent. The > camel case version (“associatedType”) does have language precedent, and I > wonder if it wouldn’t be a better choice: > > > > dynamicType > > didSet > > willSet > > > > However, there’s also precedent for making paired words all lowercase in > keywords: > > > > typealias > > fallthrough > > deinit ←(debatable: could be considered single word or > hyphenated) > > > > Perhaps keyword capitalization conventions deserve some attention across > the board. > > I thought the rules were: > - property/method: lowerCamelCase > - language keyword: lowercase > > I consider > - dynamicType as a property > - didSet, willSet, deinit as methods. > - typealias, fallthrough as language keywords > > And “associatedtype” would be a language keyword too, so it is lowercase 😊 > > Loïc > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution