[swift-evolution] [Review] SE-0122: Use colons for subscript declarations

[L. Mihalkovic]

Regards
LM
(From mobile)

On Jul 20, 2016, at 2:16 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:

>> On Jul 19, 2016, at 10:50 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution