[fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

Michael Van Canneyt michael at freepascal.org
Thu Jul 4 17:36:43 CEST 2019



On Thu, 4 Jul 2019, Sven Barth via fpc-devel wrote:

>
> Your argument works if you start with a string that's started with a
> backtick, but not correctly terminated.

To be correct, I think the argument about unterminated line endings 
needs to be seen for what it is: a nuisance, but not more a nuisance
than a mismatched {$IFDEF}.

It is correct that it will be more difficult to determine where it
goes wrong. If there are no backticks in the rest of the file, the compiler
will reach EOF, and has only the starting line to report.

In case of 2 backtick strings, you will get more difficult situations

for example:

const
   a = `this will be unterminated
with 
some
lines in it.

Var
   B : String;

begin
   B:=`
again
something
end backticked`;

end.

In this case you will get either a 'Unknown identifier "again"' or 'Semicolon expected"'
where the "again" is located or somesuch.

(Ben, what does the patched compiler report in this case ?)

So the compiler will correctly give an error.

The above example will be trivially resolved. 
If you have a file of several thousands lines long, the actual error may be 
located somewhere in these thousands of lines: The error is not 'local', 
which it definitely is in the case of a simple one-line string.

But as I pointed out: 
The same can be said about unbalanced $IFDEFS (the compiler also can only
report the first one) and we have that 'feature' too.

IMO the real concern is still clear lack of control of line ending:

Here you are still at the mercy of the settings of the IDE/Editor used, or even
the version system you use. If you work in team, someone else's editor can
mess up your string without your knowledge.

If the editor of someone else or git replaced CRLF with LF, then this can wreak
havoc in windows.

And this can not be waived aside: you must provide an unambiguous solution for this:
It definitely is the duty of the compiler to make sure a program behaves consistently,
regardless of the whitespace/EOL handling of your editor of choice.

This can be a directive, or whatever, but without a solution for this, the chances of
getting multiline strings accepted in the compiler are simply zero.

so e.g. a 
{$MULTLINESTRINGLINENDING crlf|cr|lf|platform|raw}


Michael.


More information about the fpc-devel mailing list