[swift-evolution] multi-line string literals.

[LM]

Inline

Regards
LM
(From mobile)

> On May 2, 2016, at 2:23 PM, John Holdsworth <mac at johnholdsworth.com> wrote:
> 
> 
>> 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.

I think you are correct, I am looking at Parse.cpp and further down the pipeline.

Here is a 1¢ thought born out of this exploration: 

%1 = _"[aapl_sil]"\
// inline sil code (macro-like)
...
// more code
...
"_

Just a different kind of string literal contents... understood by the ide (completion/syntax chk) and processed by the compiler at the right stage. Who knows where really adventurous devs might take something like this?


> 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/e536239b/attachment.html>