If for some reason I actually want trailing spaces in the multiline string literal, I will surely not use the new style syntax. But someone will.
And some day I will open some unit from some library written by someone -- a unit which has a new syntax string literal with trailing spaces, and the IDE will just change this string. I will open that unit to see some other code, some function far from that string, I will not be aware of the string existence.
And of course that could seriously affect the programme behaviour.
Ah, the old "contrived problem that almost certainly will never, ever actually occur as described in real life, and is
highly unlikely to be a significant issue if it did due to what the vast majority of likely use cases for the feature are" tailor-made scare-mongering. Yawn.
The bottom line is:
I have literally said I could probably modify that feature of Lazarus to ignore multi-line strings without too much of an issue, and that I would be willing to do so (despite the fact I generally disagree that
FPC needs to specifically cater to arbitrary
Lazarus IDE features. They are two separate things.)
I
do not however believe that 99% of the people who will
ever use multi-line strings will do so in a way where the existence or non-existence of trailing whitespace between the last
visible character and the newline character will actually matter to them in any way whatsoever, due to the fundamental nature of what strings are used for in the vast majority of cases (i.e. displaying information!)
This is of course
very different from
leading whitespace, which does indeed affect the formatting (hence why I introduced the MultiLineStringTrimLeft directive.)
We are talking about a programming language where anybody can, for example, just casually drop into inline assembly in the middle of their Button.OnClick() regardless of whether or not they have
any idea what they're doing, and cannot reasonably expect the compiler
or Lazarus to "save them from themselves" in the event they screw something up. And this is fine! It is what separates Pascal from nominally "safer" but objectively less powerful languages such as Java, e.t.c.
This is mind, do you not see how
ridiculous it is to then apply this
massive double standard that treats strings as
way more critical than they ever commonly are in reality, and goes "it is
unacceptable if every editor that anyone might ever code Pascal in does not fully and entirely account for this new language feature IMMEDIATELY!"
Am I supposed to go and start writing Vim / Emacs / Sublime Text / Visual Studio Code / e.t.c. plugins just to really make sure no poor, innocent programmer blows their leg off while using these dangerous, complicated multi-line strings (because it's not like their editor configuration is their own responsibility! That's crazy!) then? Where does it end?
Even if no editor
ever directly supported multi-line strings in any capacity, the chances of their use in a codebase causing you any kind of serious problem is
remarkably low, and it is disingenuous to claim otherwise.