Raw string literals -- restarting the discussion

[elias vasylenko]

Sure I do realise it looks similar to the Swift approach, I noticed that
someone had brought theirs up. It's the difference in the way it's defined
which I believe is significant, i.e. the insistence that the delimiter is
technically invariable.

For comparison, the middle ground between me and Swift is roughly just to
copy their way but use backslashes instead of hashes (i.e. as per my
original email).

*Visually* the only difference there is that by my proposal the closing
delimiter is preceded by the backslashes rather than followed by them,
which is certainly minor (and arguably less pretty I concede).
*Conceptually* though my way feels far simpler to me ... but of course
that's only valuable if users would feel the same way.

Also you probably have noted that the closer following of the Swift model
described above introduces an ambiguity between a *closing-delimiter* and a
*quote-followed-by-an-escape-sequence*. In fact my "magic-number" example
in the previous email would have fallen afoul of that.

So either the escape-marker would have to contain one more slash than the
delimiter, or we'd need to bung in an extra rule that quotes need to be
escaped *if and only if* they're followed by an escape sequence.

Well that's my case made, thanks for tossing this into the stew.

On Wed, 16 Jan 2019 at 13:40, Brian Goetz <brian.goetz at oracle.com> wrote:

> So bringing all this together I have a serious proposal for a formalisation of rawness which I think is fairly unique, but which is internally consistent and imo easy to understand and satisfies all your use-cases.
>
>
> This sounds a lot like what Swift does.
>
>     var s = \"Hello, World\"; // a raw string!
>
>
> Jim has already noted how using \” as a raw delimiter has the effect of
> suggesting the escaping is “distributed over the string”, which is a nice
> trick.
>
> Swift unifies raw and escaped strings in this manner, by parameterizing on
> the number of #.  Unfortunately, if we try to emulate this exactly, because
> of choices we’ve already made (for the zero-backslash case), we end up with
> an asymmetry that the Swift approach lacks.
>
> Still, this approach is something we are considering as a possible
> inspiration.
>
> Thoughts? I think it's fairly "Java-like", doesn't introduce too many new concepts, and looks familiar due to adapting existing concepts and notation. Hopefully not deceptively familiar.
>
> There are some good thoughts in here.  Will toss those into the stew and
> stir….
>
>