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

[mipri]

On Wednesday, 4 December 2019 at 11:10:45 UTC, Dennis wrote:
> I do believe for most of these you can use ``, q{} and q"<>"
> with little problems, but I understand that you prefer the
> q"EOS EOS" ones and would not want to rewrite your old code.

The big (and only) advantage of HERE docs is that you so rarely
have to think about them or revise them that this is not a
concern. "Check and see if you've broken the string literal" is
not a step that you go through every single time you have to
touch the content of the string. The most annoying part of HERE
docs for code presentation, that the ending delimiter has such
strict requirements, is precisely what makes them not annoying
at all for holding random snippets of HTML or whatever. You
just don't get collisions, or they are very obvious. The
reader's ease is repeated in the ease that tools have with
them: they don't need a stack; they can just read lines and
throw them away until they find a line that (classically) has
some exact contents, or (in D) starts with some exact prefix.

With only matching nested delimiter strings, accidental
collisions will happen. Not often. But neither " or ])>} are
infrequent characters to find randomly in a string, and the
first time you have to change both ends of a q"( string to make
it a q"[ string because you added a URL that ended in
parentheses to some embedded HTML, you'll think: man, I should
just take all these snippets and stuff them under __EOF__ ,
then read that statically, and stuff them into a map on module
load.

And *then* you'll think: wait, people hardly ever use __EOF__
in D, so someone's definitely going to come along and deprecate
*that* code, too!

The world isn't divided only between good practices and bad
practices. Across from the Scylla of legacy-code-is-sacred
languages that never remove anything, even obviously bad
features that nobody likes (' as a module separator in Perl, or
octal literals that start with 0), there's a Charybdis of
code-is-always-bitrotting languages that jerk you around with
pointless deprecations.

> It seems to me D has this history of removing small features
> with a small problem:
>
> - Small feature: escape string literals
>   Small problem: doesn't have much use

I was surprised when \e didn't work. So it was removed for such
a reason.

> - Small feature: octal string literals
>   Small problem: can be confused for decimal literal, and can
> be made a library feature

This is a significant problem actually. The *only* reason
languages have C-style octal literals is because they can't
remove them anymore. It's not "octal literals" in general that
are bad because they could be made a library feature. 8#123 and
0o123 are octal literals that don't get confused with a nice
decimal number like 0123.

> - Small feature: hexstring literals
>   Small problem: can be better represented in a library function

What these removals all have in common is that the post-removal
experience is: you reach for the removed feature, you get an
error, you find out what to do instead, and then there are no
more problems for you. Yes, you're still moving towards
Charybdis with stuff like this, but the point of the myth isn't
"all movements in the direction of Charybdis are bad.", as
those movements are still movements *away* from Scylla.

Removing HERE docs, though, makes the language permanently
more annoying to use for the task that would've benefited from
them. To the point that, rather than just use the intended
replacement, people might rather do something else entirely.
Someone might personally not like the look of \033 vs. \e, or
octal!123 vs. 0123, but the replacement doesn't make them work
any harder.

It's not a huge problem, but it's a difference between this
small deprecation and the previous ones.

> Now I understand that reviewers are debating whether it is a
> small feature ("I actually use these a lot") and whether the
> small problem isn't too small ("making D lexers still isn't
> hard"). That's what I like to see in the review, thanks
> especially to WebFreak and Adam D. Ruppe for their input on
> their VSCode and Vim highlighters, and thanks to you for your
> use cases.
>
> What I don't get is why this is called a "non-starter" by
> Andrei and a "debacle" / "misguided quest" by you. Is it such a
> ludicrous idea to deprecate this particular part of the
> language?

1. It's *because* the proposed change isn't that bad that it's
getting the responses it's getting, rather than complaints that
the proposed change is very bad and that HERE docs are
irreplaceable treasures. It wasn't until my post just now that
anyone took the time to say that HERE docs have any unique
advantages at all.

2. Andrei's response isn't just "non-starter" but also "HERE
documents have no impact on the language grammar."