[swift-evolution] Thoughts on replacing \() with $() or some other symbol

Jeremy Pereira jeremy.j.pereira at googlemail.com
Wed Jun 22 10:30:15 CDT 2016


I find it somewhat disturbing that we are now trying to base language design around the layout of a US English keyboard.

“\” on my keyboard (British Macbook Pro Retina) is right next to the return key. It’s also much closer to the parentheses characters than $ is and (if you assume we are going to replace parentheses with braces as was suggested upthread) right next to the brace keys. 

Anyway, your heat map evidence actually negates the argument. If it was a frequently used key, it would have a hot spot of its own. It’s not (I tried it on some random samples of my own code), so that implies it is not a key that is used very often, which further implies it *should* be a little out of the way.

*The* escape character for strings is “\”. Please let’s not introduce a second one.


> On 22 Jun 2016, at 00:08, Brandon Knope via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Actually… we can go pretty scientific on this sort of thing and heat map keyboard usage to get a better picture of how “usable” this is.
> 
> I pasted a file that contains seven \’s in it and heat mapped it at https://www.patrick-wied.at/projects/heatmap-keyboard/
> 
> Even *with* several \’s throughout my source file the majority of my key presses take place much closer to the $ key than the \ key.
> 
> I think we can all argue about what is clearer or not, but I think for the majority of us, the \ key is quite inconvenient compared to the keys around where we type the most.
> 
> I also ran several of iOS 10’s sample code through the heat map and continue to get pretty similar results: the \ is much further from the hottest part of the keyboard than the ones closer to where your hand usually rests.
> 
> Maybe this is flawed, but I think it is hard to argue that the \ is easy to type when there are far more usable alternatives.
> 
> Brandon
> 
> 
> 
>> On Jun 21, 2016, at 6:10 PM, Daniel Resnick via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I also disagree for the same reasons that Gwynne and Brent mentioned: I find '\(...)' easy to read, fine to type, and consistent with other string escaping syntax.
>> 
>> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> > I find that typing \(var) is very disruptive to my typing flow. The more I code in Swift, the more I like it, but every time I'm coding and then have to hiccup while typing \ then ( causes me to be annoyed. I know, it's minor, but it isn't a key combination that flows quickly.
>> >
>> > I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps @() to go along with other uses of @ throughout the language.
>> 
>> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I immediately liked `\(…)`. It's parsimonious: Rather than taking a third character (besides \ and ") to mean something special in a string literal, it reuses one of the existing ones. There's no need to escape a character you wouldn't otherwise have to touch, or to think of another character as "magical" in a string. It fits nicely with the rest of the syntax, with `\` indicating a special construct and then `()` delimiting an expression, just as they do elsewhere in the language. It's an elegant solution to a problem traditionally solved inelegantly. It's very Swifty in that way.
>> 
>> > A shifted key, like $ or @, followed by another shifted key like (, allows for a much faster flow and they are much closer to the home keys than \ which is nearly as far from home keys as possible (and awkward).
>> 
>> 
>> I don't have any trouble typing it personally. If you find yourself accidentally typing `\9` or `|(`, we could probably offer an error for the former or warning for the latter with a fix-it. But if you're complaining that it takes a tiny fraction of a second longer to type than `$(` would, then honestly, I just can't bring myself to care. Swift optimizes for code reading. If we wanted to optimize for code typing instead, we'd have a very different style.
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list