From lazarus at mfriebe.de Fri Apr 24 10:33:57 2026 From: lazarus at mfriebe.de (Martin Frb) Date: Fri, 24 Apr 2026 10:33:57 +0200 Subject: [fpc-other] test Message-ID: <398e995a-8190-4bca-b0c0-d506fa27c3ec@mfriebe.de> test From lazarus at mfriebe.de Fri Apr 24 10:37:48 2026 From: lazarus at mfriebe.de (Martin Frb) Date: Fri, 24 Apr 2026 10:37:48 +0200 Subject: [fpc-other] [fpc-pascal] Info about the -Mdelphi mode In-Reply-To: <0d4fea6f-03f6-483a-8d1a-7e3d524f9c57@mfriebe.de> References: <21519436.Y9LZMa1g7v@graeme-linux-desktop> <7a221bb19b67315571ddcaa4eed62929@freepascal.org> <8774722.NVGHFGmpDH@graeme-linux-desktop> <0d4fea6f-03f6-483a-8d1a-7e3d524f9c57@mfriebe.de> Message-ID: <84f83e0a-7c94-4313-bebf-e3dd88f89264@mfriebe.de> On 24/04/2026 10:12, Martin Frb via fpc-pascal wrote: > CC'ed to fpc-other at lists.freepascal.org => for follow ups > > On 23/04/2026 15:23, Graeme Geldenhuys via fpc-pascal wrote: >> >> https://blogs.embarcadero.com/introducing-inline-variables-in-the-delphi-language/ > Apart from the general yes/no question.... > (and I haven't looked deep into language design..., still...) And I completely missed "ref counted interfaces adhere to the sub-scope" Only, wasn't it established, that the lifetime of those was not documented, and therefore it was ok that with FPC it was determined by "last use" rather than "end of procedure" (which used to cause some discussions too). So, if "inline var" was copied, in FPC that life time wouldn't change... While Delphi now has some "not in the doc, but other" mention of this being a "suddenly valid" use case. From lazarus at mfriebe.de Fri Apr 24 10:12:59 2026 From: lazarus at mfriebe.de (Martin Frb) Date: Fri, 24 Apr 2026 10:12:59 +0200 Subject: [fpc-other] [fpc-pascal] Info about the -Mdelphi mode In-Reply-To: <8774722.NVGHFGmpDH@graeme-linux-desktop> References: <21519436.Y9LZMa1g7v@graeme-linux-desktop> <7a221bb19b67315571ddcaa4eed62929@freepascal.org> <8774722.NVGHFGmpDH@graeme-linux-desktop> Message-ID: <0d4fea6f-03f6-483a-8d1a-7e3d524f9c57@mfriebe.de> CC'ed to fpc-other at lists.freepascal.org => for follow ups On 23/04/2026 15:23, Graeme Geldenhuys via fpc-pascal wrote: > On Thursday, 23 April 2026 10:53:02 BST michael via fpc-pascal 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/ 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: