Inline Regards LM (From mobile)
> On May 2, 2016, at 2:23 PM, John Holdsworth <[email protected]> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
