(not so) raw strings

Evolution Pitches
1

The discussions about raw strings probably burnt some magnitudes more time than their implementation, so I try to keep it short...

Summary

The design that currently has the most support includes custom delimiters for "regular" strings as well (using the hash character).
Example: "example\\\"backslash\"" == #"example\\"backslash""# // true

example\"backslash"

Idea

I'd like to build a tiny piece on top of that concept and not only treat double quotes as regular characters unless they are accompanied by the right number of hashes, but apply the same logic to backslashes.

Example:

print(#"The "backslash" has a special meaning, thus \(1 + 1) is replaced with #\(1 + 1)#")

would output

The "backslash" has a special meaning, thus \(1 + 1) is replaced with 2

Explanation

Current string literals have no # in front of them, and nothing would change here. But if you want to use a literal that contains either a double quote and/or a backslash, you prepend the opening and closing quotes with #, and leave the string itself untouched.
If you need #\ or #" in the string itself, you keep adding more hashes.

Downsides

Well, if your string contains long sequences of hashes followed by backslash, "real raw" strings would be slightly more comfortable. I don't think that scenario is common, though.
Also: Source files with many number signs... but if you don't like those, you probably should avoid strings containing them ;-) (and it should also be possible to use \ or ` instead).

Benefits

No need to escape backslashes or double quotes inside strings while retaining the ability to perform interpolation. Imho this is a critical feature for most kinds of templating, where you have a stream of characters with small parts that are generated.

2

This should really go into the existing thread. IMO it's poor taste to declare the existing thread as too long and start a new thread to draw attention to your spin on the topic; that does nothing to help bring the discussion toward a conclusion, and in fact can have the opposite effect, diffusing the discussion among multiple topics.

4 Likes
3

I agree. Tino, do you want me to move this post or just close this thread?

4

Short story:
Do whatever you consider appropriate - apparently, I just have no idea how to channel the attention of the elite towards the content I want to be noticed.

Long story

I started there, because I wanted to discuss this idea as a possible improvement... it just was completely ignored.
Being quite convinced of the concept, I had to decide either to annoy the thread starters with something they don't want to talk about, or to start a new thread... after all, this basically makes raw strings superfluous, so the concept can be seen as a competitor.

I'm not that sure that keeping everything in one thread is always the right choice for rivaling concepts, and that splitting might improve discussion by moving the focus towards improving potential solutions, instead of making alternatives look as bad as possible. That might be wrong as well, but imho it's still worth trying.

The irony is that in the meantime, the very same idea I wanted to propagate here emerged again in the original thread, and seems to gain some traction... ¯_(ツ)_/¯