Hi,

I was reading the latest documentation (https://www.freepascal.org/docs-html/ user/userse35.html) and noticed the following:

The Delphi mode of the compiler tries to mimic Delphi as closely as possible.

and

Delphi compatibility is relatively complete up to Delphi 7. New constructs in higher versions of Delphi (notably, the versions that work with .NET) are not supported.

Delphi 7 and Delphi.NET are extremely old by 2026 standards. Is there currently a definitive Delphi version that FPC aims to be compatible with? Additionally, is there a formal roadmap or list of modern language features that the team is currently cloning or aiming to implement in -Mdelphi mode?

Regards,
Graeme

Op 22-4-2026 om 08:55 schreef Graeme Geldenhuys via fpc-pascal:

Delphi 7 and Delphi.NET are extremely old by 2026 standards. Is there currently a definitive Delphi version that FPC aims to be compatible with?

No. Adding compatility features is not synchronized with any Delphi version, the above are just approximations.

Full compatibility with D2009 and beyond is difficult because the defaults are not unicodestring. (work is done on an unicodertl for that)

Additionally, is there a formal roadmap or list of modern language features that the team is currently cloning or aiming to implement in -Mdelphi mode?

Not that I know of.  Most of "new" language features in Delphi in recent years has been relatively shallow.

There is a patch to add ternary support waiting in the MR list. Other than that I have no knowledge of missing delphi things except inline variables.

Michael.

BST michael wrote

Other than that I have no knowledge of missing delphi things except inline variables.

I just just reading a article from a few years ago, explaining the pros and cons of inline variables. It actually made a really good case for that. There is a open MR for inline variables already - just not review/merged.

https://blogs.embarcadero.com/introducing-inline-variables-in-the-delphi-language/

I was looking through the RTL and noticed FPC's 'main' branch has TCustomAttribute implemented since a few years, but still the [weak], [unsafe] and [volitile] are not implemented yet. :-)

Any word on multi-line text blocks? ;-) Coming from Java, I so MISS that in Object Pascal! :-D

Regards,
Graeme

CC'ed to => for follow ups

Apart from the general yes/no question....
(and I haven't looked deep into language design..., still...)

If for arguments sake, it was a yes:

1) "begin/end" are compound statements, not scopes (even mentioned on the big forum thread)
2) If a "inline scope" existed, no mention of "inline var" only at the start thereof.
3) same keyword "var" but significant difference: block vs single statement (one var only)

Currently (not tested), but from description

    if foo then begin
       writeln;
       var bar: integer = 1; // mid (implied) scope
       readln;
     end;

So within the "for arguments sake", shouldn't it then be

    if foo then
       // optional introduction of new keyword to start scope
       var // "var" starts scope (and must be followed by "begin"
          bar: integer = 1;
          bar2: integer = 2;
      begin
         writeln;
         readln;
      end;

- Without a "scope keyword" => "var" starts the new scope. That scope covers the next statement  (which must be compound begin/end).
- var block ends at begin (which starts the statement for which the scope will last)

And the "for var i :=
is inconsistent. Its the only one that allows "var" mid-statement. (wel, its the only(?) LHS that can be mid statement...)

Any word on multi-line text blocks? ;-) Coming from Java, I so MISS that in Object Pascal! :-D

Aren't they in 3.3.1 already? And 2 forms? backtick and multi-single-quote?

Op 24-4-2026 om 10:12 schreef Martin Frb via fpc-pascal:

(also, many people want to read in that stack layout follows the nesting of inline variables. I however think that there is no direct relation between declaring and where the stackframe is created. (probably once at the beginning only) But I don't have a new enough Delphi, and the thread died before anybody answered)

"it was always a thing in the one most of us care about". Why the coy reference? What language is that, that I'm supposed to care about?

"a major smell in the pascal language" - nope. A minor C.

26. dubna 2026 1:46:17 SELČ, Warren Postma via fpc-pascal napsal:

I sincerely hope, that _if_ it ever gets supported, the implementation is strictly restricted to $MODE DELPHI and its documentation is accompanied with a bold warning like "Although this option became supported in FPC due to improved Delphi compatibility, it should be strongly discouraged because it is not compliant to Pascal."

Tomas

Op 26-4-2026 om 01:46 schreef Warren Postma via fpc-pascal:

Every modern language has inline variabler declarations because it was always a thing in the one most of us care about.

Opinion based on extrapolating languages that directly or indirectly inherit from eachother.

Not having inline variables means that our strongly typed language Pascal doesn't have as precise a scoping of variables as possible, preventing read access before initialization, which is a major smell in the pascal language and compiler designs.

Contrary to original C , we can now use more than 32kb for compilers now and have static analysis to prevent this, should it be necessary.

Copying your "tone" in my answer below...

Warren Postma wrote

Not having inline variables means that our strongly typed language Pascal doesn't have as precise a scoping of variables as possible, preventing read access before initialization, which is a major smell in the pascal language and compiler designs.

<sarcasm> Yes, </sarcasm> Just look at JS to see how well it works

     function a() { "use strict";  var x = b; var b; return b;} a();

The above compiles and runs just fine. Clearly "preventing read access before initialization".
<sarcasm> But, its very popular, so we should definitely copy that </sarcasm>

IIRC JS has now a linter, trying to get rid of the problems they created. But you want that we go introduce some part of that.... Really?

BST Tomas Hajny wrote

it should be strongly discouraged because it is not compliant to Pascal.

Ummm... Let's use examples:

var in a parameter list. Meaning: pass by reference. var inside a procedure/function block. Meaning: variable declaration.

Same keyword, yet two totally different meanings. But hey, everyone is okay with that.

There is already a clear precedent for 'var' having different meanings depending on context. An inline var simply defines and scopes a variable at the point of use. I see no harm is supporting it.

FPC already supports things like Generics and anonymous functions in some modes (which definitely weren't in Wirth's original Pascal), the "not compliant" argument feels a bit like moving the goalposts.

It's called language evolution.

Regards,
Graeme

Every modern language has inline variabler declarations because it was always a thing in the one most of us care about.

Not having inline variables means that our strongly typed language Pascal doesn't have as precise a scoping of variables as possible, preventing read access before initialization, which is a major smell in the pascal language and compiler designs.

Warren

On Fri, Apr 24, 2026 at 1:53 AM Marco van de Voort via fpc-pascal <

25. dubna 2026 21:09:55 SELČ, Graeme Geldenhuys via fpc-pascal napsal:

On Saturday, 25 April 2026 18:38:09 BST Tomas Hajny via fpc-pascal wrote: > it should be strongly discouraged because it is not compliant to Pascal. Ummm... Let's use examples:

.
.

It's called language evolution.

Your examples are (mostly) new features rather than changes to the syntax rules of the language. While weakening previously existing rules may be considered "evolution", others may consider them degradation.

Tomas

Failure to track valuable delphi capabilities and compatibilotu reads as people being stuck in the mud of “we never dun it this way before”.

On Sun, Apr 26, 2026 at 4:41 AM Tomas Hajny via fpc-pascal <