This is getting somewhat off topic, wouldn't it be nice if Xcode didn't strip leading whitespace when pasting into string literals? Is there a reasonable rationale for the current behavior? In my experience it only causes frustration.
Use the Paste and Preserve Formatting command from Xcode's Edit menu.
1 Like
cmd-alt-shift-V
Hard to type. Easy to love.
Thank you!
Yes, thank you! I still don't think stripping leading whitespace in strings and comments makes sense for the default paste command but it's great to know this option exists as a workaround.
Another workaround is swapping the keyboard shortcuts of those paste commands, in the Key Bindings pane of Xcode's preferences.
I love where this ended up, thanks for all the hard work put into the design!
3 Likes
The moment you add interpolation, you don’t have a raw string. From a purest stand point I just feel like it completely misses the point.
What is the functionality that doing this leaves out, or is worse?
Whether or not it gets called a raw string probably isn’t that important if it solves the right problems.
2 Likes
Which languages of the ones listed in the proposal support interpolation in raw strings?
Java is the only one that I found that acknowledges possible support in the future.
Java: http://openjdk.java.net/jeps/326
"Raw string literals do not directly support string interpolation. Interpolation may be considered in a future JEP."
I am not saying we should not do it but I do not think it should be done in this proposal.
-
It is distracting from the main feature. I think it is premature.
-
It has the potential to block us when we try to do regex strings.
-
pure raw strings could potentially be optimized if it is known that they do not include any interpolation.
That is all I have to say about it for now.
A side note. Someone on the internet is wrong:
" Python, Kotlin, Groovy and Swift have opted to use triple double quotes to indicate raw strings.
"
In case it's helpful to anyone else reading the proposal...
It took me a little while to fully understand the behavior of the new #-enhanced escape sequences.
For me, the key was separating the ideas of "backslash" and "escape delimiter" in my head. In most (all?) programming languages I've used, if there is an "escape delimiter", it is always a single backslash.
With this proposal, that is not the case. The "escape delimiter" is now a variable-length combination of backslash and pound-sign characters, just like the "string delimiter" is a combination of double-quote and pound-sign characters.
For example:
| String Start | Escape | String End |
|---|---|---|
" |
\ |
" |
#" |
\# |
"# |
##" |
\## |
"## |
#######" |
\####### |
"####### |
Additionally, inside the string:
- Any backslash that is followed by too few pound signs (like
\#in a##""##string) is not an escape delimiter. It is just that exact string. - Any backslash that is followed by too many pound signs (like
\##in a#""#string) creates an invalid escape sequence because it is an escape delimiter followed by a pound sign.
6 Likes
This is how I understand it too.
So, what do we do when the raw string actually does have a backslash followed by a lot of pound signs? For example, if we have a backslash followed by 10 pound signs, but no other pound signs anywhere else in the string, can we use a single "#" as part of the delimiter? Or do we have to use at least 11 pound signs in the delimiter?
This proposal prefers to solve real problems than provide the truest "raw" experience so, yes, you will have to use 11 or more pound signs in the delimiter or you can use string interpolation to get the same result without the excess pound signs.
(or better, what Brent says just below)
Yes, actually. In a single-pound string, \#\ produces an escaped backslash, so #"\#\##########"# will produce the string you want.
2 Likes