Thoughts on replacing \() with $() or some other symbol

Hi all,

I'm new to the list and I just searched through the archives as best I
could to see if someone else had already brought this up, but I didn't find
anything. Forgive me if this horse has been beaten.

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.

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).

Thoughts?

Kenny Wyland
InADayDevelopment.com

I'm forced to agree that \ is quite awkward for something that may be
used so pervasively, and $ would likely meet more peoples' expectations.

···

on Tue Jun 21 2016, Kenny Wyland <swift-evolution@swift.org> wrote:

Hi all,

I'm new to the list and I just searched through the archives as best I
could to see if someone else had already brought this up, but I didn't find
anything. Forgive me if this horse has been beaten.

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.

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).

--
Dave

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

I'd support $() as is in use by other languages, including Kotlin, as mentioned it seems less disruptive and more inline with the tokenised parameters that are already supported in closures.

···

On 21 Jun 2016, at 21:43, Kenny Wyland via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I'm new to the list and I just searched through the archives as best I could to see if someone else had already brought this up, but I didn't find anything. Forgive me if this horse has been beaten.

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.

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).

Thoughts?

Kenny Wyland
InADayDevelopment.com
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Like others that have already responded, I would vote -1 to this proposal
based on evaluating the question "Is the problem being addressed
significant enough to warrant a change to Swift?" My answer to that would
be no. While it is indeed different from other languages there is no
relative difficulty in typing \( vs. any other sequence.

Thank you though for the time and thought put into writing up the
proposal. It's this level of participation from the community and ability
to share thoughts and ideas in a public forum that has made open source
Swift so attractive to many.

···

On Tue, Jun 21, 2016 at 3:43 PM, Kenny Wyland via swift-evolution < swift-evolution@swift.org> wrote:

Hi all,

I'm new to the list and I just searched through the archives as best I
could to see if someone else had already brought this up, but I didn't find
anything. Forgive me if this horse has been beaten.

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.

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).

Thoughts?

Kenny Wyland
InADayDevelopment.com

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit

If such bike-shed repainting is under serious consideration, I’d request that the tint take into account the possibility of string formatter options being desired in the future. Outside of that, I’m just as happy with the current symbol as I would be with the proposals I’ve heard so far.

-DW

···

On Jun 21, 2016, at 3:03 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Tue Jun 21 2016, Kenny Wyland <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

I'm new to the list and I just searched through the archives as best I
could to see if someone else had already brought this up, but I didn't find
anything. Forgive me if this horse has been beaten.

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.

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'm forced to agree that \ is quite awkward for something that may be
used so pervasively, and $ would likely meet more peoples' expectations.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I have to disagree - The \ syntax is consistent with other string escape sequences (\n etc.) and reads naturally to me in that regard. Additionally, the \ is very visually distinctive in a string, much moreso than the "traditional" $ variable marker. Almost every language I’ve seen using $ for interpolation in strings is doing so because it also uses it as a variable prefix in non-string contexts. To top it off, using $ instead would, for me, just add yet another language for which I have to remember "does the $ go inside or outside the name delimiter braces/brackets/whatever?", "is it parenthesis, braces, brackets, or some other delimiter for variable names?", "what kind of expressions can I use in this context?", "can I use interpolation without any delimiters for simple cases?", etc. See also PHP, Perl, ten flavors of shell scripts, JavaScript, JSP/ASP, XPath, and so forth. The \() syntax is unique to Swift and therefore very easy to remember.

I also don’t see that Swift carries an expectation of being able to use a syntax which is traditionally confined to interpreted/scripting languages, and even there $ is by no means ubiquitous. Here are just a few counterexamples among various languages:

- C (printf formats)
- C++ (stream modifiers)
- Objective-C (NSString formats)
- C# ($, but with the unusual syntax $"blah {foo} blah")
- Lua (printf formats and language hacks)
- Python (printf formats with trailing "% (tuple)" syntax)
- Ruby ("#{}")
- Java (printf formats)

There’s an obvious pattern in these example, which brings to something I _would_ like to see for string interpolation in Swift: Better control over the precise representation of the data. I’m sure the topic has been done to death many times before, but I haven’t found any solid information at a quick search, so I apologize if this is all old hat.

Anyway - Creating, configuring, and invoking various Formatter types in order to present data in the proper fashion is an option, and a preferable one when the data is intended for user consumption (especially to get the maximum support from localization). But for logging, debugging, parsing of textual formats, writing textual formats, etc., I almost always want a traditional C/POSIX/ISO representation as easily provided by printf()-style specifiers. 99% of the time when I want to do an number-to-string (integer or otherwise) conversion especially, I’m being specific about the appearance of the number.

For example, for a hex representation of sockaddr_in.sin_addr.s_addr, I would in other languages write "printf("0x%08x", address.sin_addr.s_addr);", or "%02hhu" times four to get dotted-decimal notation. (Ignoring for the moment the existence of inet_ntop() for the sake of the example :). In Swift, I currently have to make a call to printf(), fprintf(), dprintf(), NSString(format:), asprintf() (with a wrapper to deal with getting a Swift.String from allocated memory), etc. A configured NumberFormatter instance is a great deal more code - even NumberFormatter.localizedString(from: foo, number: .decimal) is very verbose, and that *still* doesn’t yield the same level of format control!).

And to top it off, these still carry the traditional problem of printf() formats - separation between the format specifier and the data that format applies to. I’m sure most of us have at one time or another written a printf() with enough arguments that it was easy to lose track of them and end up being very grateful for the existence of -Werror=format (and frustrated that __attribute__((format(..))) is as limited as it is :).

I’m not sure exactly what form support for formatted data in interpolated strings would take in Swift, but it’s certainly one of the things I find myself actively missing on a regular basis, and I do have some ideas on how to go about it, if it isn’t already under discussion/development.

-- Gwynne Raskind

···

On Jun 21, 2016, at 15:48, Jonathan Cotton via swift-evolution <swift-evolution@swift.org> wrote:

I'd support $() as is in use by other languages, including Kotlin, as mentioned it seems less disruptive and more inline with the tokenised parameters that are already supported in closures.

On 21 Jun 2016, at 21:43, Kenny Wyland via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I'm new to the list and I just searched through the archives as best I could to see if someone else had already brought this up, but I didn't find anything. Forgive me if this horse has been beaten.

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.

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).

Thoughts?

Kenny Wyland
InADayDevelopment.com <http://inadaydevelopment.com/&gt;

That said, I think it's nice that \, #, $, and @ are all used in unique
scenarios. What about going a little classical with %?

···

On Tue, Jun 21, 2016 at 16:10 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Tue Jun 21 2016, Kenny Wyland <swift-evolution@swift.org> wrote:

> Hi all,
>
> I'm new to the list and I just searched through the archives as best I
> could to see if someone else had already brought this up, but I didn't
find
> anything. Forgive me if this horse has been beaten.
>
> 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.
>
> 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'm forced to agree that \ is quite awkward for something that may be
used so pervasively, and $ would likely meet more peoples' expectations.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I agree with this; Swift’s only other dollar sign use is for closure shorthand variables, which is technically a non-string context but I assume you mean on *all* variables. Anyway, I think \() is actually a good way to do this, as it’s unambiguous, and not something you’re likely to type by mistake, since you don’t need to escape the brackets for any other purpose. The way I think of it is as an escape from the string, which is IMO more logical than a variable inside a string which dollar notation brings to mind (for me at least).

···

On 21 Jun 2016, at 22:49, Gwynne Raskind via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 21, 2016, at 15:48, Jonathan Cotton via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I'd support $() as is in use by other languages, including Kotlin, as mentioned it seems less disruptive and more inline with the tokenised parameters that are already supported in closures.

On 21 Jun 2016, at 21:43, Kenny Wyland via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

I'm new to the list and I just searched through the archives as best I could to see if someone else had already brought this up, but I didn't find anything. Forgive me if this horse has been beaten.

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.

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).

Thoughts?

Kenny Wyland
InADayDevelopment.com <http://inadaydevelopment.com/&gt;

I have to disagree - The \ syntax is consistent with other string escape sequences (\n etc.) and reads naturally to me in that regard. Additionally, the \ is very visually distinctive in a string, much moreso than the "traditional" $ variable marker. Almost every language I’ve seen using $ for interpolation in strings is doing so because it also uses it as a variable prefix in non-string contexts. To top it off, using $ instead would, for me, just add yet another language for which I have to remember "does the $ go inside or outside the name delimiter braces/brackets/whatever?", "is it parenthesis, braces, brackets, or some other delimiter for variable names?", "what kind of expressions can I use in this context?", "can I use interpolation without any delimiters for simple cases?", etc. See also PHP, Perl, ten flavors of shell scripts, JavaScript, JSP/ASP, XPath, and so forth. The \() syntax is unique to Swift and therefore very easy to remember.

Entirely agree. \ makes total sense as the one-and-only escaping character. I also have no trouble typing it.

···

On 21 Jun 2016, at 23:55, Brent Royal-Gordon via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I'll stick with Gwynne here. Each language has its syntax for
interpolating string and as such I don't see a reason to change this.
As for formatting, I agree it is an issue but we have to remember that
inside \() we have code that can do pretty much everything one may
need. You may even add a formatting function to String or Int in order
to produce the result you need (even simplifying the calls to
NumberFormatter - I myself have a whole library of "shortcuts" I add
to every project).

L

···

On 21 June 2016 at 18:49, Gwynne Raskind via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 21, 2016, at 15:48, Jonathan Cotton via swift-evolution > <swift-evolution@swift.org> wrote:

I'd support $() as is in use by other languages, including Kotlin, as
mentioned it seems less disruptive and more inline with the tokenised
parameters that are already supported in closures.

On 21 Jun 2016, at 21:43, Kenny Wyland via swift-evolution > <swift-evolution@swift.org> wrote:

Hi all,

I'm new to the list and I just searched through the archives as best I could
to see if someone else had already brought this up, but I didn't find
anything. Forgive me if this horse has been beaten.

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.

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).

Thoughts?

Kenny Wyland
InADayDevelopment.com

I have to disagree - The \ syntax is consistent with other string escape
sequences (\n etc.) and reads naturally to me in that regard. Additionally,
the \ is very visually distinctive in a string, much moreso than the
"traditional" $ variable marker. Almost every language I’ve seen using $ for
interpolation in strings is doing so because it also uses it as a variable
prefix in non-string contexts. To top it off, using $ instead would, for me,
just add yet another language for which I have to remember "does the $ go
inside or outside the name delimiter braces/brackets/whatever?", "is it
parenthesis, braces, brackets, or some other delimiter for variable names?",
"what kind of expressions can I use in this context?", "can I use
interpolation without any delimiters for simple cases?", etc. See also PHP,
Perl, ten flavors of shell scripts, JavaScript, JSP/ASP, XPath, and so
forth. The \() syntax is unique to Swift and therefore very easy to
remember.

I also don’t see that Swift carries an expectation of being able to use a
syntax which is traditionally confined to interpreted/scripting languages,
and even there $ is by no means ubiquitous. Here are just a few
counterexamples among various languages:

- C (printf formats)
- C++ (stream modifiers)
- Objective-C (NSString formats)
- C# ($, but with the unusual syntax $"blah {foo} blah")
- Lua (printf formats and language hacks)
- Python (printf formats with trailing "% (tuple)" syntax)
- Ruby ("#{}")
- Java (printf formats)

There’s an obvious pattern in these example, which brings to something I
_would_ like to see for string interpolation in Swift: Better control over
the precise representation of the data. I’m sure the topic has been done to
death many times before, but I haven’t found any solid information at a
quick search, so I apologize if this is all old hat.

Anyway - Creating, configuring, and invoking various Formatter types in
order to present data in the proper fashion is an option, and a preferable
one when the data is intended for user consumption (especially to get the
maximum support from localization). But for logging, debugging, parsing of
textual formats, writing textual formats, etc., I almost always want a
traditional C/POSIX/ISO representation as easily provided by printf()-style
specifiers. 99% of the time when I want to do an number-to-string (integer
or otherwise) conversion especially, I’m being specific about the appearance
of the number.

For example, for a hex representation of sockaddr_in.sin_addr.s_addr, I
would in other languages write "printf("0x%08x", address.sin_addr.s_addr);",
or "%02hhu" times four to get dotted-decimal notation. (Ignoring for the
moment the existence of inet_ntop() for the sake of the example :). In
Swift, I currently have to make a call to printf(), fprintf(), dprintf(),
NSString(format:), asprintf() (with a wrapper to deal with getting a
Swift.String from allocated memory), etc. A configured NumberFormatter
instance is a great deal more code - even
NumberFormatter.localizedString(from: foo, number: .decimal) is very
verbose, and that *still* doesn’t yield the same level of format control!).

And to top it off, these still carry the traditional problem of printf()
formats - separation between the format specifier and the data that format
applies to. I’m sure most of us have at one time or another written a
printf() with enough arguments that it was easy to lose track of them and
end up being very grateful for the existence of -Werror=format (and
frustrated that __attribute__((format(..))) is as limited as it is :).

I’m not sure exactly what form support for formatted data in interpolated
strings would take in Swift, but it’s certainly one of the things I find
myself actively missing on a regular basis, and I do have some ideas on how
to go about it, if it isn’t already under discussion/development.

-- Gwynne Raskind

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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.

Those are persuasive arguments. Consistency with other string escaping
syntax is a huge plus. Moreover, now that I think about it, \r or \n isn't
really a bother to type. The \( combination takes a little getting used to,
but it's not absurdly terrible. I suppose we could consider \{} or even \
instead of \() to alleviate the reach.

···

On Tue, Jun 21, 2016 at 5:10 PM, Daniel Resnick via swift-evolution < swift-evolution@swift.org> wrote:

On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

%, at least to me, suggests distant evaluation; i.e. parameter passing at
the end. $ seems more like an in-place evaluation, like how bash does it.

···

On Tue, Jun 21, 2016 at 2:14 PM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:

That said, I think it's nice that \, #, $, and @ are all used in unique
scenarios. What about going a little classical with %?
On Tue, Jun 21, 2016 at 16:10 Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

on Tue Jun 21 2016, Kenny Wyland <swift-evolution@swift.org> wrote:

> Hi all,
>
> I'm new to the list and I just searched through the archives as best I
> could to see if someone else had already brought this up, but I didn't
find
> anything. Forgive me if this horse has been beaten.
>
> 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.
>
> 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'm forced to agree that \ is quite awkward for something that may be
used so pervasively, and $ would likely meet more peoples' expectations.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha

An argument could be made that the '\' character is used to escape and when you are doing string interpolation/printing you are clearly doing an operation more similar to bash's use of '$' to extract the value of a variable than escaping.

The need to logically separate escaping from parameter value extraction/string interpolation is IMHO grounds for this change alone.

···

Sent from my iPhone

On 21 Jun 2016, at 23:35, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 21 Jun 2016, at 22:49, Gwynne Raskind via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 21, 2016, at 15:48, Jonathan Cotton via swift-evolution <swift-evolution@swift.org> wrote:

I'd support $() as is in use by other languages, including Kotlin, as mentioned it seems less disruptive and more inline with the tokenised parameters that are already supported in closures.

On 21 Jun 2016, at 21:43, Kenny Wyland via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I'm new to the list and I just searched through the archives as best I could to see if someone else had already brought this up, but I didn't find anything. Forgive me if this horse has been beaten.

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.

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).

Thoughts?

Kenny Wyland
InADayDevelopment.com

I have to disagree - The \ syntax is consistent with other string escape sequences (\n etc.) and reads naturally to me in that regard. Additionally, the \ is very visually distinctive in a string, much moreso than the "traditional" $ variable marker. Almost every language I’ve seen using $ for interpolation in strings is doing so because it also uses it as a variable prefix in non-string contexts. To top it off, using $ instead would, for me, just add yet another language for which I have to remember "does the $ go inside or outside the name delimiter braces/brackets/whatever?", "is it parenthesis, braces, brackets, or some other delimiter for variable names?", "what kind of expressions can I use in this context?", "can I use interpolation without any delimiters for simple cases?", etc. See also PHP, Perl, ten flavors of shell scripts, JavaScript, JSP/ASP, XPath, and so forth. The \() syntax is unique to Swift and therefore very easy to remember.

I agree with this; Swift’s only other dollar sign use is for closure shorthand variables, which is technically a non-string context but I assume you mean on *all* variables. Anyway, I think \() is actually a good way to do this, as it’s unambiguous, and not something you’re likely to type by mistake, since you don’t need to escape the brackets for any other purpose. The way I think of it is as an escape from the string, which is IMO more logical than a variable inside a string which dollar notation brings to mind (for me at least).
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1

I’m using Finnish keyboard, for \ the key combination is opt-shift-7, then () are shift-8 and shift-9, so very easy. Actually, using @ (opt-2) or $ (opt-4) would be harder, because one would have to switch hands, using opt with right hand and then using left hand for shift for () or opt-shift for {}.
The code is written once, but read maybe thousands of times, so readability is immensely more important.

!
! Jyrki Wahlstedt
! Homepage of Jyrki Wahlstedt Twitter: @jyrkiw
!
! Our life is no dream; but it ought to become one and perhaps will.
!

···

On 22.6.2016, at 1.10, Daniel Resnick via swift-evolution <swift-evolution@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.

+1

I’m using Finnish keyboard, for \ the key combination is opt-shift-7, then () are shift-8 and shift-9, so very easy. Actually, using @ (opt-2) or $ (opt-4) would be harder, because one would have to switch hands, using opt with right hand and then using left hand for shift for () or opt-shift for {}.
The code is written once, but read maybe thousands of times, so readability is immensely more important.

!
! Jyrki Wahlstedt
! Homepage of Jyrki Wahlstedt Twitter: @jyrkiw
!
! Our life is no dream; but it ought to become one and perhaps will.
!

···

On 22.6.2016, at 1.10, Daniel Resnick via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.

I really don't like \. I'd prefer just about any of the shift keys
(!@#$%^&).

That said, I would shut up and cope if xCode did the right thing when you
were typing a \ inside "'s and just filled in the () and placed the cursor
in the right spot. I guess that would upset folks that type a lot of
\otherstuff in "'s, but I could live with that.

···

On Tue, Jun 21, 2016 at 2:22 PM, Saagar Jha via swift-evolution < swift-evolution@swift.org> wrote:

%, at least to me, suggests distant evaluation; i.e. parameter passing at
the end. $ seems more like an in-place evaluation, like how bash does it.

On Tue, Jun 21, 2016 at 2:14 PM Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

That said, I think it's nice that \, #, $, and @ are all used in unique
scenarios. What about going a little classical with %?
On Tue, Jun 21, 2016 at 16:10 Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote:

on Tue Jun 21 2016, Kenny Wyland <swift-evolution@swift.org> wrote:

> Hi all,
>
> I'm new to the list and I just searched through the archives as best I
> could to see if someone else had already brought this up, but I didn't
find
> anything. Forgive me if this horse has been beaten.
>
> 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.
>
> 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'm forced to agree that \ is quite awkward for something that may be
used so pervasively, and $ would likely meet more peoples' expectations.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Saagar Jha

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
kurt@CircleW.org
http://www.CircleW.org/kurt/

Gwynne and Brent indeed hit on the logic for the original design: backslash is already an escape character in strings. The parentheses () over another kind of delimiter were originally to match calls (string interpolation once generated direct calls to String initializers), but even without that it’s still something that’s used with expressions, while curly braces {} are used for general code blocks and square brackets are used with collections.

I’m strongly in favor of keeping things the way they are, both because I like it a fair bit and because it’d be another source-breaking change that would be very hard to migrate.

Jordan

···

On Jun 21, 2016, at 15:26, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Tue, Jun 21, 2016 at 5:10 PM, Daniel Resnick via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.

Those are persuasive arguments. Consistency with other string escaping syntax is a huge plus. Moreover, now that I think about it, \r or \n isn't really a bother to type. The \( combination takes a little getting used to, but it's not absurdly terrible. I suppose we could consider \{} or even \ instead of \() to alleviate the reach.