If you've ever wanted to be able to use multi-line strings in FPC...

[AlexTP]

Not implemented yet, the feature-request is submitted but not solved.

[Thaddy]

pas2js already supports it.

[Ryan J]

It's been 5 years since this was discussed and developed shortly after the initial discussion. The average Pascal programmer will be 60 years old before this is ever implemented.

At the very least this should have been decided on and either given a firm "no" or have the core team decide the syntax and white space semantics and allowed to continue. At most this feature should have been developed and released within 6 months.

[bytebites]

The multiline feature has been added to the trunk version.

[jamie]

All I see is a mess!

You need to place some indication of where the trailing spaces are on each line, you can't simply trim the line like that and expect the next line to support the space!

 The lines need some sort of closure; otherwise be happy with the messes it causes when you can't see the white spaces trailing on the lines.

  It just ends up being more work to manage source code for text fields then it's worth.

 At best, the IDE would need a helper outline window to show where the trims are in the editor.

 Just more unneeded work.

[Thaddy]

Although originally conceived by Akira, it has become a Delphi compatibility "feature" and the mess is the same in our cousin.
Also note you will need a 3.3.1 main/trunk from 27-07-2025 or later.
It is enabled by default in objfpc and delphi modes.
Other modes can use it with {$modeswitch multilinestrings}
The related {$TEXTBLOCK NATIVE/CR/LF/CRLF} is also implemented.
This is a local directive.

[gues1]

These are same samples in Delphi:

Code: Pascal  [Select][+][-]

1. const
2.     strML1 = '''
3.      The quick brown fox jumps
4.      over the lazy dog.
5.      ''';
6.     strHTML = '''
7.      <UL>
8.       <LI>Item 1</LI>
9.       <LI>Item 2</LI>
10.       <LI>Item 3</LI>
11.       <LI>Item 4</LI>
12.      </UL>
13.      ''';
14.     strJSON = '''
15.      [
16.        {"id" : "1", "name" : "Large"},
17.        {"id" : "2", "name" : "Medium"},
18.        {"id" : "2", "name" : "Small"}
19.      ]
20.      ''';
21.     strSQL= '''
22.      SELECT *
23.      FROM Customers
24.      WHERE Department = 'R&D'
25.      ORDER BY Name;
26.      ''';
27.  

The unique advise is the identation: all the string lines start at the same position of the last '''. Prior spaces are not considerer, prior characters are errors (signaled by error insight from IDE).

You can act exactly like this with standard concatenation of strings. But with multistrings the IDE helps you to auto align during the digit.

I don't use them, but I think is not so terrible. Refer for Delphi: https://docwiki.embarcadero.com/RADStudio/Athens/en/String_Types_(Delphi)

[Thaddy]

The above compiles of course. Furthermore Freepascal has similar syntax checking for multiline strings, e.g:

Code: [Select]

testordinal.pas(4,9) Error: Incorrectly indented multi-line string (need 8 whitespace chars) starting at line 4, column 9.
All features that the Delphi documentation referred to above mentions work, including escaping, e.g.:

Code: Pascal  [Select][+][-]

1. {$mode objfpc}
2. begin
3. writeln('''''
4.         test
5.         '''
6.         test
7.         ''''');
8. readln;
9. end.

It also rather nicely screws up the forum's syntax highlighter...

[Warfley]

Great the introduction of significant whitespace is what was missing in Pascal... Also it treats tabs and spaces equaly, which means here both are equally aligned:

Code: Pascal  [Select][+][-]

1.   WriteLn('''
2.  Test
3.                 Test  
4.  ''');

Not to mention the confusion this is going to cause:

Code: Pascal  [Select][+][-]

1. WriteLn('''Test''');

[gues1]

Great the introduction of significant whitespace is what was missing in Pascal... Also it treats tabs and spaces equaly, which means here both are equally aligned:

Not in Delphi, the tabs are converted in spaces in the IDE editor (I don't know about external editors).

These are the results:

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. begin
3. AllocConsole;
4. writeln('''
5.   Test1
6.        Test2
7.   ''');
8. writeln('''TEST''');
9. end;

Test1
       Test2
'TEST'

And is like should be, not confusion.

By the way, like I told I don't use that but I understand that in some cases this can be usefull.

EDIT: allign the result like they are in the reality, not like they were showed in "QUOTE" section

[Thaddy]

Also, there is a bug: backticks crash the compiler, but should be perfectly legal:

Code: Pascal  [Select][+][-]

1. {$modeswitch multilinestrings}
2. begin
3. writeln('''
4.          `
5.         ''');
6. end.

That seems a remnant from Akira's original proposal/patch, which used backticks.
Not very smart because backticks are firmly in the 1..127 range and the compiler can already handle #39 (tick) properly.
No need to escape more.
The bug is in the scanner.

[Warfley]

Not in Delphi, the tabs are converted in spaces in the IDE editor (I don't know about external editors).

These are the results:

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. begin
3. AllocConsole;
4. writeln('''
5.   Test1
6.        Test2
7.   ''');
8. writeln('''TEST''');
9. end;

Test1
       Test2
'TEST'

Now open the same file with an editor that is configured to use tabs instead of spaces and add a new line and see how this thing is burning
Not everyone uses the same editor and not everyone configures their editor the same. Also if the editor changes the indentation of untouched lines it completely breaks any source control, so I doubt Delphi is doing that (can't verify tho).

It's not hard to imagine a project with 1 person using tabs and the others using spaces, I've worked with such projects. The language should not break down for this.

In my example above the first line uses 2 spaces and the second one uses 2 tabs. FPC treats them as the same indentation, even though the latter should be twice the indentation.

[Thaddy]

Code: C  [Select][+][-]

1. Console.writeline("""Test""");

Works as a normal multiline string, because there is no ambiguity that needs to be resolved with significant newline

That is not really relevant for the syntax in Object Pascal, where '''  would be already ambiguous otherwise, so it needs something different.
What's more worrying is that it seems easy to find bugs. I found two, related to backticks: one that crashes the compiler and one that gives spurious syntax errors.

[Warfley]

The C# one was actually a bad example, because there they do distingish between single line """ and multiline """ strings (first one are raw byte strings).

A better example would be python, where the following is possible:

Code: C  [Select][+][-]

1. print("""Line1
2. Line2""")

So even a language that has significant whitespace does not need significant whitespace for multiline strings

[nomorelogic]

Hello everyone,
I wanted to share my view on multi-line strings.
It's not a particularly original idea, but it's inspired by various ‘Pascal server pages’ such as:
https://www.yanniel.info/2011/12/pascal-server-pages-script.html

Explanatory code follows:

Code: Pascal  [Select][+][-]

1.  
2.  
3. program test01;
4. const LE = #10;
5. var s1, s2, s3: string;
6.     d: TDate;
7. begin
8.    
9.   d:= encodedate(2025, 07, 28);  
10.   s1 := {$MULTILINESTRING_RAW_BEGIN} // all ignored until EOL, auto-idented by 8
11.         SELECT o.*, C.Company{$PAS:LE}
12.         from Orders O{$PAS:LE}
13.         join Customer C{$PAS}LineEnding{$RAW}
14.           on o.CustNo=C.ID{$PAS:LE}
15.         where{$PAS}LE{$RAW}
16.           O.saledate like '{$PAS}FormatDateTime('yyyy', [d]){$RAW}%';
17.         {$MULTILINESTRING_RAW_END}
18.  
19.   Writeln(s1);  
20.  
21.   // MULTILINESTRING_OS_BEGIN means:
22.   // same as MULTILINESTRING_RAW_BEGIN but all EOL are replaced by LineEndig
23.   s2 := {$MULTILINESTRING_OS_BEGIN} // all ignored until EOL, auto-idented by 8
24.         SELECT o.*, C.Company
25.         from Orders O
26.         join Customer C
27.           on o.CustNo=C.ID
28.         where
29.           O.saledate like '{$PAS}FormatDateTime('yyyy', [d]){$RAW}%';
30.         {$MULTILINESTRING_OS_END}
31.  
32.   Writeln(s2);  
33.  
34.   // MULTILINESTRING_SQL_BEGIN means:
35.   // same as MULTILINESTRING_RAW_BEGIN but all EOL are replaced by space (#32)
36.   s3 := {$MULTILINESTRING_SQL_BEGIN} // all ignored until EOL, auto-idented by 8
37.         SELECT o.*, C.Company
38.         from Orders O
39.         join Customer C{$PAS}  /* need spaces before EOL? -> */     {$RAW}
40.           on o.CustNo=C.ID
41.         where
42.           O.saledate like '{$PAS}FormatDateTime('yyyy', [d]){$RAW}%';
43.         {$MULTILINESTRING_SQL_END}
44.  
45.   Writeln(s3);  
46.  
47. end;
48.  

What do you think?

Thanks
nomorelogic


Edit:
correction in code


Edit 2:
Here is a brief explanation:

The directive {$MULTILINESTRING_OS_BEGIN} is equivalent to a single apostrophe but activates a multiline string

The directive {$PAS:LE} consists of two tokens:
- ‘{$PAS:’ activates Pascal mode, while ‘}’ closes Pascal mode and returns to multiline string mode; in this case, it writes the constant LE to the string

The directives {$PAS} and {$RAW}, respectively:
- activates Pascal mode
- activates raw mode (back to multiline string)

The directive {$MULTILINESTRING_RAW_END} closes multi-line string mode