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

David Rönnqvist david.ronnqvist at gmail.com
Sun Jun 26 13:12:45 CDT 2016


I prefer "\" as the consistent escape character in Swift. It's used in many programming languages and (I find it) easy to skim over. 

- David

> On 23 Jun 2016, at 22:21, James Hillhouse via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I’m going to register a -1 on this proposal. I appreciate the work that went into it, but I just don’t think any advantages for the developer community as a whole weight enough to warrant the change.
> 
>> On Jun 23, 2016, at 4:41 AM, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On 22 Jun 2016, at 17:27, Brandon Knope <bknope at me.com> wrote:
>>> 
>>> Of course \ is not needed a lot but when it is, *it is inconvenient for *some* people*. I am not making this up. You can cite several other users from this very thread.
>> 
>> That’s the point. Convenient key stroke sequences should be used for things you need a lot before things you don’t use a lot. 
>> 
>>> 
>>> I tried showing that it is quite distant on the keyboard from where the user’s hands rest. I tried showing that there are other keys at their finger tips where their hand is usually resting.
>>> 
>>> 1. Do I know every international keyboard layout? No.
>>> 2. Are we pretending that \ was picked because it was easier for international users? If I am wrong, I would love to hear more…else let’s not pretend that \ was the optimal key for all.
>> 
>> No, it was picked because it is the escape character for strings. The escape character(s) for strings need to be few in number (one is ideal IMO) and characters that you aren’t likely to need to type in a string as literals. $ is a particularly bad choice due to its popularity as a currency symbol.
> 
> Changing this would add more syntax, make layers in usage where one character now exist, and does so without offering a large material advantage, imho.
> 
>> 
>>> 
>>> Like I have said repeatedly…I don’t care if \ is removed. At this point we are wasting other people’s time. I have just tried to be a voice for those that find it awkward and inconvenient.
>> 
>> I would challenge the claim that on a US keyboard or a British keyboard, the \ key is inconvenient to type. In both cases, you don’t even have to press the shift key. If you are a touch typist (I’m not), it’s a slight stretch for the right hand, but no more so than the return key or backspace (I use backspace *a lot*).
> 
> Compared to typing Obj-C' [], which was when was tired “=“ “delete” or “]” “\”, Swift in general, including \(), is a breeze. 
> 
>> 
>> However, I do find the \( *combination* a little awkward but this is because of the way I normally type the (, but I would find having to type \$ every time I wanted a dollar sign intensely annoying because it is so unnecessary.
>> 
>> 
>>> I tried not to base this just on opinion but on some *evidence*, but apparently that isn’t sufficient enough for some.
>> 
>> And I was just trying to point out that the evidence you presented does not show what you think it does. If you present evidence, I’m allowed to dispute it aren’t I?
>> 
>>> 
>>> Brandon
>>> 
>>> 
>>>> On Jun 22, 2016, at 12:20 PM, Jeremy Pereira <jeremy.j.pereira at googlemail.com> wrote:
>>>> 
>>>> 
>>>>> On 22 Jun 2016, at 17:02, Brandon Knope <bknope at me.com> wrote:
>>>>> 
>>>>> No it shows where your hand frequently is also
>>>> 
>>>> And you don’t think there is a correlation between where the frequently pressed keys are and where your hands are? If you were needing to press the \ key a lot, there would be a hotspot over it. Then you could say “look, I need to press this key a lot and it’s miles away from the other hotspot”. 
>>>> 
>>>>> 
>>>>> Brandon
>>>>> 
>>>>>> On Jun 22, 2016, at 12:01 PM, Jeremy Pereira <jeremy.j.pereira at googlemail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 22 Jun 2016, at 16:41, Brandon Knope <bknope at me.com> wrote:
>>>>>>> 
>>>>>>> My point was not to argue for the removal of \. My point was that there is a measurable way to test the usability of such a key
>>>>>> 
>>>>>> 
>>>>>> Your heat map doesn’t test the usability of a key, it tests the frequency with which it was pressed. The fact that there was no coloured blob on the backslash key just means you don’t use it very often.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Brandon
>>>>>>> 
>>>>>>>> On Jun 22, 2016, at 11:30 AM, Jeremy Pereira <jeremy.j.pereira at googlemail.com> wrote:
>>>>>>>> 
>>>>>>>> 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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160626/3ddc4f22/attachment.html>


More information about the swift-evolution mailing list