> On Dec 23, 2015, at 12:41 PM, Chris Lattner <clatt...@apple.com> wrote: > > On Dec 23, 2015, at 10:25 AM, Dave Abrahams <dabrah...@apple.com> wrote: >>> Of the three, I prefer “associatedtype”. >>> >>> We already have precedent for concatenated names in a very related sort of >>> decl (typealias), and this will be a real keyword. >>> >>> >>> Here are how I see the pros and cons I see of these options: >>> >>> type: >>> - Overly short, particularly given the infrequency of these decls, the >>> common case of “type Element” will be weird floating around given its lack >>> of weight. >> >> I don’t understand how that’s different from, e.g. >> >> init() >> >> or >> >> var x: Int >> >> which will both show up in protocol declarations. Could you explain? > > It follows from the same logic that makes “typealias” have a long name, > instead of being named “type” or “typ” ;-) > > typealiases and associated types are both *much* less frequently used than > variables or functions. var and func make sense to keep very short because > of their frequency, and because every swift programmer is expected to > memorize what they do. “init” is less defensible on these terms, because it > is more rare, but is clear, and shares commonality with some ObjC heritage. > > If you compare typealiases and associated types, these are *much* more > infrequently used than any of these three, they are effectively a advanced > generics feature. Because they are less frequent, people shouldn’t be > expected to memorize what they are, and googlability does matter. > > >>> - Overly unclear. This is a very specific kind of type, not a generic type >>> you can use in other contexts. >> >> Could you explain what you mean by this? If anything I see this exactly >> opposite. It’s a requirement for a type, *any* kind of type, be it struct, >> class, enum, non-nominal type such as tuple or function, whatever—so long as >> it satisfies the constraints placed it. That’s about as generic as one can >> get. > > This is a declaration of a requirement of a type. This is not declaring a > type. This keyword cannot be used in any other place in the grammar. People > would reasonably expect to use a keyword like “type” elsewhere. This keyword > is completely different than init/var/func in that sense. > >>> - Unfortunate keyword. Among other things it would make writing compilers >>> in swift a pain :-), but again, people would want to use this in other >>> places. >> >> I don’t see how this would actually cause a problem if it was contextual. > > Besides the parser ambiguities? We could probably force it to work, but it > would be unnecessary complexity. All statements and decls should start with > a keyword. This enables attributes and declmodifiers to “just work”, you > lose that if you play games with context sensitive keywords. > >> There’s no reason one couldn’t name a property “type” if one wanted to. >> These two things will appear in *very* different contexts, so I don’t think >> humans would have a hard time de-contextualizing. > > I agree, that’s exactly why I don’t think it should be called “type”. They > are very different things.
Thanks for explaining, Chris. -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
