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

[J. Gareth Moreton]

On 04/07/2019 06:31, Sven Barth via fpc-devel wrote:
> Am 04.07.2019 um 01:57 schrieb J. Gareth Moreton:
>>
>> While I like the idea in principle, one thing that I'm a bit worried 
>> about is how whitespace is handled, like what counts for a leading or 
>> trailing space in the string when between lines, since Pascal parsers 
>> (and those for many other languages) traditionally, I believe, 
>> discard everything following the last non-whitespace character in a 
>> line.  Also, with the backtick suggestion, what should one do if they 
>> wish to include a control character (e.g. a linefeed) or the backtick 
>> character itself?
>>
> Whitespace is indeed an important point. I myself pay quite some 
> attention to nice identation and with multiline strings that will 
> probably break:
>
> === code begin ===
>
> const SomeString = `Whatever
>                                      bar
>                                      blubb
>                                      foobar`;
>
> === code end ===
>
> That's how I also inline my normal multiline strings that I separate 
> with sLineBreak. However to get the same result with this proposed new 
> feature I'd have to do this:
>
> === code begin ===
>
> const SomeString = `Whatever
> bar
> blubb
> foobar`;
>
> === code end ===
>
> Which looks just ugly.


I can definitely see that being a sticking point for such a feature with 
no easy way to solve it, except to introduce a $INCLUDESTRINGFILE 
compiler directive, since if the string is so long that it requires the 
spanning of multiple lines and not using the existing means of extending 
a Pascal string onto multiple lines, then it probably should be stored 
in an external text file to be merged upon compilation.

It's a shame, because I like the feature in principle, but the 
whitespace problem is a bit of a deal-breaker for me.  Also, things like 
trailing spaces and the line terminators being either #10 or #10#13 may 
cause a lot of problems if the string has to be known exactly (e.g. for 
cryptographic hash generation).

Gareth aka. Kit


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus