Regards LM (From mobile)
On Jul 20, 2016, at 2:16 PM, Brent Royal-Gordon via swift-evolution <[email protected]> wrote: >> On Jul 19, 2016, at 10:50 PM, Chris Lattner via swift-evolution >> <[email protected]> wrote: >> >> * What is your evaluation of the proposal? > > I think the colon has too little visual weight for this role. In a property > declaration, the colon sits to the right of an identifier: > > var widgetID: WidgetUUID > > But in a subscript, it sits to the right of a long, punctuation-filled, and > potentially convoluted parameter list: > > subscript(id widgetID: WidgetUUID): Widget { … } > > In this environment, the colon vanishes. You trumpet it like it is a universal truth... I have been back into lots of ts for 2 weeks now and low and behold none of the colons have vanished yet ;-) More seriously, I think u underestimate the way the brain just adapts. None of this is hard to read: interface Hashable { getHash(): number } Interface Dictionary { [name:string]:string|number } interface T extends Hashable { } class SomeTypeName<Type extends Hashable> { public getHash():number { return ...; } public type():this { return Type; } } function compare<T1 extends T, T2 extends T>(lhs:SomeTypeName<T1>, rhs:SomeTypeName<T2>):boolean { return lhs.getHash() != rhs.getHash(); } and neither is this: export function newDataStore<T extends DataStore<U>, U> (ctor: { new (config:DataStoreConfig):T}, config:DataStoreConfig):T { return new ctor(config) } > Using arrow instead gives us a symbol that not only stands out more, but > which is conventionally given spacing on both sides. Both of these assist you > in seeing the symbol, helping you visually parse the declaration. It also > helps that this symbol is not the same one used at least once and sometimes > more often within the parameter list itself. > > Thus, we have the current syntax: > > subscript(id widgetID: WidgetUUID) -> Widget { … } > > I understand where the impulse comes from, I really do. Looked at as an > abstract question, colon is more correct, because there's no function > involved here. But subscript syntax faces many of the same challenges that > led to the adoption of the arrow in functions, and I think we have to go > where those human factors lead us. > >> * Is the problem being addressed significant enough to warrant a change >> to Swift? > > Yes, I think proposals on this topic are appropriate. > >> * Does this proposal fit well with the feel and direction of Swift? > > No; I think that's where this proposal falls down. Swift happily emphasizes > clarity over purity, and I think arrow is clearer. > >> * If you have used other languages or libraries with a similar feature, >> how do you feel that this proposal compares to those? > > Off the top of my head, I can't think of one with an analogous issue. > >> * How much effort did you put into your review? A glance, a quick >> reading, or an in-depth study? > > Glance. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
