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

[H. S. Teoh]

On Tue, Dec 03, 2019 at 03:09:19PM +0000, Dennis via Digitalmars-d wrote:
[...]
> I don't propose deprecating token strings, only the identifier
> delimited ones, which get highlighted as strings.
> 
> ```
> string s = q{
> this is fine
> };
> 
> string t = q"EOS
> this is not fine
> EOS";
> ```

The problem is that token strings require the contents to be *D tokens*.
So if I need to emit snippets of another language, I'm out of luck, and
have to resort to quoted strings and Leaning Toothpick Syndrome.

I oppose this DIP.

1) It puts undue focus on a marginal, non-intrusive language feature and
   makes it seem as if it's a primary cause of tooling problems (it does
   add some complexity, no doubt, but let's not make mountains out of
   molehills here);

2) It places the blame of the syntax highlighting issue at the wrong
   place: syntax highlighters should be fixed, not the other way round.

3) It does not adequately strive to understand why heredoc syntax was
   introduced in the first place, where/when it might be useful, and how
   to mitigate the problems heredoc syntax solves if we were to remove
   it;

4) It breaks a pretty long list of existing D projects, yet does not
   provide strong enough benefits to justify this breakage (doubly so
   for me, because I don't use syntax highlighters to begin with, so for
   me this is all loss and no gain);

5) The breakage does not unquestionably improve code, in fact, I can
   already see many cases for which it makes code *less* readable;

6) The amount of work it will take to rewrite heredoc literals far
   outweighs any small benefits this DIP might bring (and in my case,
   it's work for *no* benefit).


T

-- 
Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine