[swift-evolution] multi-line string literals.

[L. Mihalkovic]

On May 2, 2016, at 1:49 AM, Brent Royal-Gordon <brent at architechies.com> wrote:

>>    • using the default string literal recognition mechanism binds us to have to ‘wait’ a bit in order to figure which kind of string literal we are dealing with (single/multi line)
> 
> Part of the idea of the continuation quotes proposal is that there *is* no distinction between a single-line literal and a multi-line literal. There are just string literals, which may include one line or many.
> 
> And in general, part of the advantage of this proposal is precisely that it has such low impact on the parser and lexer, and the grammar more generally. It is currently illegal to open a string and fail to close it on the same line, so we are just giving that obviously illegal construct an interpretation. By extending the existing feature, we get a whole lot of stuff for free:
> 

I appreciate how easy it is to retrofit some multiline literal behavior without touching much as demonstrated by John's code (I also implemented a different patch that isolates all code changes inside a couple new methods and generates the existing string_literal token).

The problem I am facing is that I also want to support "ZERO massaging" schemes (direct past without editing the lines), and so far I have not seen how to do it without opening a wider whole through the parser/lexer. I chose to make a parallel route simply to avoid risking making my code a merge nightmare as soon as the core team touches anything in the vicinity.


> * We don't have to worry about whether `|>` or `@|` or whatever construct you end up using might, in some place where you could otherwise use a string literal, be confusable with some other construct.
> * We don't have to worry about whether obscure corners of the language, like the string parameters to `@available`, support multiline string literals (they do, automatically).
> * We don't have to do a huge amount of redesigning in the lexer, and I doubt we'll have to touch the parser at all (the prototype doesn't).
> 
> It seems a bit backwards to propose we introduce a separate path for lexing multiline strings, and then complain that one of the proposals on the table makes it difficult to tell which path you should take, when the proposal in question is specifically designed to make having a separate path unnecessary.

Just to be sure, I am complaining about anything, but merely referencing an argument I read in one of John Holdsworth's recent contribution. Regarding the "unnecessary separate path", IMHO it depends on what the end game is supposed to look like (as previously stated, I want to try tagging the contents of multine literals, which makes them different from single line ones), and at what horizon.

No matter what, you are the experts... I just appreciate how easy the quality of the codebase makes prototyping some of these ideas.

King regards