[swift-evolution] multi-line string literals.

[John Holdsworth]

> I'm having trouble getting the `e` modifier to work as advertised, at least for the sequence `\\`. For example, `print(e"\\\\")` prints two backslashes, and `print(e"\\\")` seems to try to escape the string literal. I'm currently envisioning `e` as disabling *all* backslash escapes, so these behaviors wouldn't be appropriate. It also looks like interpolation is still enabled in `e` strings.
> 
> Since other things like `print(e"\w+")` work just fine, I'm guessing this is a bug in the proposal's sketches (not being clear enough about the expected behavior), not your code.
> 
> I've written a gist with some tests to show how I expect things to work:
> 
> 	https://gist.github.com/brentdax/be3c032bc7e0c101d7ba8b72cd1a692e

The problem here is that I’ve not implemented unescaped literals fully as it would require changes outside the lexer.
This is because the string is first lexed and tokenised by one piece of code Lexer::lexStringLiteral but later
on in the code generation phase it generates the actual literal in a function Lexer::getEncodedStringSegment.
This is passed the same string from the source file but does not know what modifiers should be applied. As a result
normal escapes are still processed. All the “e” flag does is silence the error for invalid escapes during tokenising.

        assert( e"\w\d+\(author)\n" == "\\w\\d+\(author)\n" );

Having encountered this limitation I managed to persuade myself this is what you want anyway but perhaps few would agree,
What has been implemented is more of an r”” than a e”” that solves the “picket fence” problem where you can also interpolate
into convenient regex literals. This is all beyond the scope of this proposal anyway so I’ll leave that battle for another day.
The changes to the compiler for anything else would be a step up in terms of disruption.

>> and one new feature that \ before a newline ignores the newline.
> 
> This is in the "Future directions for multiline strings" section of the proposal. Having implemented this, how do you feel about it? Does it seem like such a no-brainer that we should just incorporate it into the proposal?

I agree, lets move it into scope.

Latest toolchain with the ability to have more than one modifier as you suggest is now:
http://johnholdsworth.com/swift-LOCAL-2016-05-02-a-osx.tar.gz

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160502/7ec4fbcd/attachment.html>