DIP 1026---Deprecate Context-Sensitive String Literals---Community Review Round 1

[Dennis]

On Tuesday, 3 December 2019 at 23:13:16 UTC, aliak wrote:
> 1) Are there any examples of strings that don't have an 
> in-source code workaround if this dip is accepted?

Considering escape sequences such as "\x0B" and string 
concatenation with ~, any string literal can still be expressed. 
The generic, most non-intrusive transformation I can think of 
would be:
Given an identifier delimited string, check which of < ( { [ has 
the least amount of mismatched brackets. Then convert the string 
literal to a bracket delimited string with all unmatched brackets 
concatenated in:
```
q"EOS
((["`[<< { ((["`[<<
EOS"

// only one mismatching {, so it becomes

q"{((["`[<< }" ~ "{" ~ q"{ ((["`[<<}"
```

(This is a worst case example, in practice I expect there to be 
not so many mismatched brackets and quotes/back ticks in a string 
literal)

> 3) how much less complex does the parser actually get? Is it 
> trivial?

In dmd not so much, it would just make this function a bit 
smaller:
https://github.com/dlang/dmd/blob/073b6861b1d1a9859a90e25c8d7f079b54280aca/src/dmd/lexer.d#L1477

For implementations of a D lexer in lexer/parser generators (e.g. 
http://dinosaur.compilertools.net/lex/index.html), it means only 
needing context-free constructs to express everything.