A syntactic change: blocks as statements
lazarus / 64-FPC development

----------------------------------------------------------------------
xixixi · 2023-06-17 18:01

What do you think about changing the definition of structured
statement from:

structured statement: compound statement
                      conditional statement
                      repetitive statement
                      with statement
                      exception statement
to:

structured statement: block
                      conditional statement
                      repetitive statement
                      with statement
                      exception statement
?

The change is backwards-compatible and allows to introduce inner
scopes.

A sample of how code would look:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i begin   
DoThings;    // ....    WriteLn('Hashtable contents:');    var       
k: string;    begin        for k in myhashtable.Keys do         
const            v = myhashtable[k];          begin           
WriteLn(k, ' -> ', v);          end;  // scope of v ends here    end;
 // scope of k ends here    // ...    DoOtherUnrelatedThings;end;

----------------------------------------------------------------------
Martin_fr · 2023-06-17 18:07

Apart from the new name: Old topic. "inline var declarations" (and the
like) have been discussed lots and lots of times.

Search the old conversations. See what was already discussed (before
repeating it yet another time).

Then, if you really have something that is truly groundbreaking new on
the topic => present it, and show by direct comparison how it differs
from the existing....

----
My 2 cents.

----------------------------------------------------------------------
xixixi · 2023-06-17 18:25

Quote from: Martin_fr on June 17, 2023, 08:07:21 pmThen, if you really
have something that is truly groundbreaking new on the topic =>
present it, and show by direct comparison how it differs from the
existing....

From the existing what? Proposals, or current language?

----------------------------------------------------------------------
Martin_fr · 2023-06-17 18:40

Where your proposal is different from the existing proposals. (Other
than giving the idea a new name)

You are of course free to just repeat the exact same (or very similar)
ideas/statements/proposals that have already be made.
But what is the point of it?

Or do you want to repeat the same and expect a different outcome....
?   SCNR


-- Just to add: This is my personal opinion. Not posting this as
admin/moderator. So wherever this topic goes, at current is not
limited.

----------------------------------------------------------------------
440bx · 2023-06-17 19:36

Quote from: xixixi on June 17, 2023, 08:01:35 pmWhat do you think
about changing the definition of structured statement from:
Instead of changing the definition of structured statement I would
much prefer having inline scopes which gives the programmer everything
inline variables provide and then some (scoped inline type and
constant definitions along with breakable scoped statements, all of it
fully in the spirit of J&W's Pascal.)

You can find an example of inline scopes at https://forum.lazarus.free
pascal.org/index.php/topic,43172.msg323311.html#msg323311

That feature would allow writing significantly simpler and cleaner
code and, would also allow the compiler to optimize code more easily.

----------------------------------------------------------------------
Martin_fr · 2023-06-17 19:46

Well, all of that actually already exist (but for the optimization).

In trunk, there are anonymous functions. Just inline one of them,
including a call.
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i procedure
Foobegin  DoFoo;  // Start scope or block or whatever you want to name
it  procedure ()   var a: TBar;  begin  end(); // invoke here 
ContinueFoo;end;
Since no reference is kept to the anonymous function, the compiler
could easily optimize it. (Such optimization would have to be written
in any case... So adding it here, is no harder than creating a new
feature to which it then still has to be added).

----------------------------------------------------------------------
Warfley · 2023-06-17 20:39

There are I think exactly 2 use cases where inline variables would be
useful:
1. for For loops, because here you usually use the typical iterator
names (i, j, k, m, etc.) and these are only used for this single loop,
and having them in your variable definition just takes space without
adding much information.
Also right now you are restricted to having only one type, inline
variables would allow:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i for var i:
Integer in IterateIntegers do for var i: QWord in IterateQWords
doToday if you have such a situation you need to to have seperate
itaration variable for the other loop, and it happend to me more than
once that I accidentally wrote the name of the variable of a
previously used loop (I often just brainlessly type "i" as iterator
variable, because I'm so used to it). Because those variables are
available in the same function, it is easy to accidentally use them
and it compiles happiely and you wonder why nothing is working.

The second point is for scoped lifetime, as managed records now
provide the capability to have automatic lifetime management, one
could imagine writing to a file like that:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i
FileStream.Open(FileName);FileStream.WriteLn('Hello File');The problem
is that the finalizer will only be called at the end of the function,
meaning the file will stay open until then. So a solution to this may
be to use scopes:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i with var
FileStream: TFileStream dobegin  FileStream.Open('FileName'); 
FileStream.WriteLn('Hello File');end;
Aside from these two I don't see much reason to do so. When you are at
a point where you have so many variables that you may get confused and
need to introduce scoping, that is usually a sign that you are having
to much code in one function, and should rather split it up into
multiple functions.

Note that you can also use nested functions to retain scope:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i procedure
Foo(param: Integer); var  x: Integer; procedure PrintXAndParam;begin 
WriteLn(x, param); // As nested function it has access to the
variables defined before it and to the parametersend; begin  x := 42; 
PrintXAndParam;end;That said, I think you should design your program
in a way that you encapsulate your functionality such that you don't
need to rely on much state anyway.

I have never found a program where a really big function was actually
necessary and could not be encapsulated into multiple smaller
functions.

Note that not having inline variable definitions was a key design
decision for pascal by Wirth, where other languages at the time where
not going that route, and the reason for this is that it can keep the
code cleaner. That said of course if you have giant functions with
paragraphs of variable definitions in the front, this can have the
opposite effect, but as I said, in this case you should cleanup your
code and not try to "fix" the language to work better with messy code.

----------------------------------------------------------------------
440bx · 2023-06-17 20:41

Quote from: Martin_fr on June 17, 2023, 09:46:09 pmIn trunk, there are
anonymous functions. Just inline one of them, including a call.
Functionally that seems to implement local scopes, however, since the
local scope is being implemented using an anonymous
function/procedure, a stack frame, which is unnecessary in the case of
a local scope, is created.

Thank you though, for some reason I had not thought about using the
new anonymous functions to implement local scopes.

----------------------------------------------------------------------
Martin_fr · 2023-06-17 20:49

Quote from: Warfley on June 17, 2023, 10:39:23 pmThe problem is that
the finalizer will only be called at the end of the function, meaning
the file will stay open until then.
Is that so? As in, is that documented?

Because I recall that people couldn't use the "interface trick" for
finalization, because unlike the non-documented behaviour in Delphi,
Fpc would free them at an earlier time. Or maybe I recall it wrong,
it's a long long time ago.

----------------------------------------------------------------------
Warfley · 2023-06-17 20:55

Quote from: Martin_fr on June 17, 2023, 09:46:09 pmIn trunk, there are
anonymous functions. Just inline one of them, including a call.
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i procedure
Foobegin  DoFoo;  // Start scope or block or whatever you want to name
it  procedure ()   var a: TBar;  begin  end(); // invoke here 
ContinueFoo;end;I know anonymous functions are really useful, but this
syntax is so ugly and cluttery. I still believe that this was an April
Fools joke by someone at Embarcadero, but he forgot to tell anyone so
it was integrated into the language.

Quote from: Martin_fr on June 17, 2023, 10:49:49 pmIs that so? As in,
is that documented?

Because I recall that people couldn't use the "interface trick" for
finalization, because unlike the non-documented behaviour in Delphi,
Fpc would free them at an earlier time. Or maybe I recall it wrong,
it's a long long time ago.
You are right it is undocumented, which makes it actually even worse
for such cases (if it's documented it's at least predictable), but I
remember from my own tests a few years ago that FPC would call it at
the end of the function. At least when used as such:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i with
FileOpen do // Returning a Managed Record Filestream  WriteLn('Hello
File');
It would be really neat if the with statement would have a defined
scope lifetime for managed types. That said, I don't like the with
statement because of it's shadowing, i.e. when you are in a with and
both your current Self and the with have the same Identifiers it can
get confusing (e.g. in the example above with Record.WriteLn vs
System.WriteLn)

----------------------------------------------------------------------
BeniBela · 2023-06-17 20:56

Quote from: Martin_fr on June 17, 2023, 08:07:21 pm
Then, if you really have something that is truly groundbreaking new on
the topic

Relatively new is that Delphi added inline var declarations


Now fpc needs it too for Delphi compatibility

Delphi compatibility is more important than syntax penchants

----------------------------------------------------------------------
Martin_fr · 2023-06-17 21:03

Quote from: BeniBela on June 17, 2023, 10:56:40 pmQuote from:
Martin_fr on June 17, 2023, 08:07:21 pm
Then, if you really have something that is truly groundbreaking new on
the topic

Relatively new is that Delphi added inline var declarations

Had been mentioned in previous discussions.

----------------------------------------------------------------------
Warfley · 2023-06-17 21:18

Quote from: BeniBela on June 17, 2023, 10:56:40 pmRelatively new is
that Delphi added inline var declarations

I understand why Embarcadero did this (to allow type inference, which
is extremely valuabe especially with generics), but like with pretty
much all their language design decisions, while the idea is decent,
the implementation isn't.

The reason why Pascal has a fixed location for all variable
definitions is so it is easy to reckognize where something is, and it
keeps the actual functionality in the code clean from "boilerplate"
code.
The problem with the new inline variables in Delphi is that they are
to "easy", in the sense that when you can just write your variable
definition inline there is no need to do the extra work to put them in
the definition section of the header. This incentivises you to always
prefer this, which results in less readable code, as adding a bunch of
definitions inline as just statements will basically just add noise to
the actual function of the code blocks it is in.

A much better way would have been to have an explicit structure around
them, like with:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i with var i
:= 42 do  // use i in with block
This allows for having scoped lifetime and visibility, seperates it
clearly from instruction statements, and while being readable when
used in moderation, exessive use of nested scoping withs will result
in alot of boilerplate, incentivising to use the proper definition
space whenever possible, and making this clearly an exception to the
rule that should only be used when necessary.

A language should make it "painful" to write bad code and rewarding to
write good code, and the upmost priority should always been writing
readable code with as little noise as possible.
But Embarcadero is just really bad at making good design decisions.

----------------------------------------------------------------------
xixixi · 2023-06-17 21:27

Quote from: Martin_fr on June 17, 2023, 09:46:09 pmWell, all of that
actually already exist (but for the optimization).

In trunk, there are anonymous functions. Just inline one of them,
including a call.
That's exactly what I thought when I saw the announcement of anonymous
functions; that having them it's only a small step to have inner
blocks/scopes.

It isn't as straightforward though. Result and Exit need to be fixed
to refer to the outer function, "free" break and continue need to be
changed to refer to encompassing loops, and maybe goto need to be
allowed to cross blocks in this case.

Maybe other fixes as well.

----------------------------------------------------------------------
xixixi · 2023-06-17 21:44

Quote from: 440bx on June 17, 2023, 09:36:10 pmInstead of changing the
definition of structured statement I would much prefer having inline
scopes which gives the programmer everything inline variables provide
and then some (scoped inline type and constant definitions along with
breakable scoped statements, all of it fully in the spirit of J&W's
Pascal.)

You can find an example of inline scopes at https://forum.lazarus.free
pascal.org/index.php/topic,43172.msg323311.html#msg323311

That feature would allow writing significantly simpler and cleaner
code and, would also allow the compiler to optimize code more easily.

Sure. It's a good idea for inner scopes to have a header. Actually, it
would be necessary if the code shown by Martin_fr ends up being valid,
since a block can start with any of label, type, const, var,
procedure, function, etc... I thought none of those keywords could
start a statement, but if that isn't the case, then a header is
needed.

----------------------------------------------------------------------
Peter H · 2023-06-18 03:42

Quote from: Warfley on June 17, 2023, 10:55:34 pmCode: Pascal
 [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i   procedure
()   var a: TBar;  begin  end(); // invoke here 
I know anonymous functions are really useful, but this syntax is so
ugly and cluttery. I still believe that this was an April Fools joke
by someone at Embarcadero, but he forgot to tell anyone so it was
integrated into the language.

At least current Delphi does not support this syntax with appended
brackets.
This is a unique Free Pascal feature, SCNR.
Edit: C++ supports it too, but Delphi does not.

It can be written like this in Delphi:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i   const
someproc = procedure ()               var a: TBar;          begin    
    end;  someproc();  // invoke here 
Inline variables and inline constants and type inference make this
possible.
This is more versatile.
In Free Pascal it is not possible to declare an anonymous procedure as
a constant.

The purpose of this construct is not immediately clear, at least it
was not clear to me, until I learned it:

This construct can be used in functional programming to capture outer
variables into a local context. 
(Local visibility, but global lifetime, until the context is not
referenced anymore and released)

----------------------------------------------------------------------
Warfley · 2023-06-18 08:07

But why is this only possible with inline definitions?

There are two types of const, there are untyped and typed consts.
Untyped consts are compile time only constructs, basically macros.
They cannot have runtime implications. E.g.
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i const  C =
42;begin  WriteLn(C);  WriteLn(C);end; // Is runtime translated
tobegin  WriteLn(42);  WriteLn(42);end;The constant does not exist
after compilation anymore and can therefore not exerpt any runtime
behavior. If what youve wrote is an untyped  constant, the following
would happen:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i const
someproc = procedure ()              var a: TBar;          begin     
   end; someproc();someproc(); // Would be translated toprocedure () 
var a: TBar;beginend(); procedure ()  var a: TBar;beginend();Note that
because at runtime those are two completely different instantiations,
there is no connection between the two "A" variables here, so no state
is captured in between.

The alternative are typed constants, which is a misnomer, as in
reality they are just static (global) lifetime local scope variables,
and then what you posted is in reality just them in combination with
type inference, so
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i const
someproc = procedure ()  var a: TBar;beginend; // is justconst
someproc: reference to procedure = procedure()  var a:
TBar;beginend;But then there is absolutely no difference from doing
that:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i const 
someproc: reference to procedure = nil;begin  if not
Assigned(someproc) then    someproc = procedure()    var      a:
TBar;    begin    end;end;
QuoteThis construct can be used in functional programming to capture
outer variables into a local context.
(Local visibility, but global lifetime, until the context is not
referenced anymore and released)Thats not from functional programming
but from prototypical programming, which is often clustered together,
due to it's reliance on runtime function manipulation, but there is a
big difference, functional programming is stateless ("pure") and there
is no concept of variables or variable lifetime. A real functional
program is so pure that it doesn't even require your computer to be
powered to run.

But thats just on a side note. More importantly, this is used in such
languages to emulate the behavior of static lifetime variables (such
as writable consts in pascal), which those languages are usually
lacking. So you are currently introducing a hack to emulate a hack
that tries to emulate a feature we already have.
Just skip the middle man:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i const 
GlobalLifetimeA: TBar = nil;var  a: TBar;begin  if not
Assigned(GlobalLifetimeA) then    GlobalLifetimeA := a;end;

What I think pascal is truely missing is truely constant typed consts
that can be assigned later, something like this:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i const 
MyConst: Integer; // Note no assignment herebegin  WriteLn(MyConst);
// Not assigned yet, compiler error  MyConst := 42; // first
assignment, will be unchangable from now  WriteLn(MyConst); // Works
because already defined  MyConst := 32; // Compiler error: trying to
reassign constend;
Maybe even with a special keyword to make this more clear:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i const 
MyConst: Integer; unassigned; // Note no assignment herebegin  assign
MyConst := 42;  MyConst := 32; // error  assign MyConst := 32; //
errorend;
But a real notion of consts is what is defenitely lacking

----------------------------------------------------------------------
PascalDragon · 2023-06-18 20:04

Quote from: Warfley on June 17, 2023, 10:55:34 pmYou are right it is
undocumented, which makes it actually even worse for such cases (if
it's documented it's at least predictable), but I remember from my own
tests a few years ago that FPC would call it at the end of the
function. At least when used as such:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i with
FileOpen do // Returning a Managed Record Filestream  WriteLn('Hello
File');
It's not documented, so don't rely on it. The behavior might be
changed to improve optimization. Delphi recently changed that behavior
as well to be more like FPC's behaviour because it allows for better
optimizations.

Quote from: BeniBela on June 17, 2023, 10:56:40 pmNow fpc needs it too
for Delphi compatibility

Delphi compatibility is more important than syntax penchants

With the introduction of inline variables to Delphi we have decided
that this might not necessarily be the case considering many of the
core devs (especially those that would be able to implement this) are
against this feature.

----------------------------------------------------------------------
kupferstecher · 2023-06-19 09:46

Quote from: Warfley on June 18, 2023, 10:07:30 amWhat I think pascal
is truely missing is truely constant typed consts that can be assigned
later, something like this:
[...]
Maybe even with a special keyword to make this more clear:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i const 
MyConst: Integer; unassigned; // Note no assignment herebegin  assign
MyConst := 42;  MyConst := 32; // error  assign MyConst := 32; //
errorend;
But a real notion of consts is what is defenitely lacking

I think its really not a good idea to have runtime stuff in consts.
Because one couldn't use this const to define the value of an other
const, also it uses memory even if it isn't used (But could be
optimized away).

So the later-assigned-const should rather be a special variable. E.g.:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i var 
MyConst: Integer; const; // can only be assigned oncebegin  Assign
MyConst := 42;  MyConst := 32; // Error: Constant variables can not be
assigned in a statement, use 'assign' instead  Assign MyConst := 32;
//Error: Dublicate initialization of constant variableend;
[hypothetical code]


Quote from: PascalDragon on June 18, 2023, 10:04:07 pmWith the
introduction of inline variables to Delphi we have decided that this
might not necessarily be the case considering many of the core devs
[...] are against this feature.

Thats good to hear!

----------------------------------------------------------------------
marcov · 2023-06-19 10:03

Quote from: PascalDragon on June 18, 2023, 10:04:07 pmWith the
introduction of inline variables to Delphi we have decided that this
might not necessarily be the case considering many of the core devs
(especially those that would be able to implement this) are against
this feature.

IIRC everybody was nearly universally against it, but it was
acknowledged that if it gets too prevalent we might have to change. 

The fact that more and more delphi users are on subscription, and thus
the latest version, makes new features migrate through codebases much
faster. It is hard to predict how that will work out longer term. In
the past the mix in versions was a break on new features use by e.g.
open source projects and component vendors.

But to avoid constant discussion and pressure about when, it was
decided to park it for at least 5 years and to discourage delphi users
of using this feature if they want to be compatible within that
period.

And even if it is implemented in trunk at some point, it being in
release versions is probably even further away, given current release
circles.

----------------------------------------------------------------------
wp · 2023-06-19 10:05

Quote from: PascalDragon on June 18, 2023, 10:04:07 pmWith the
introduction of inline variables to Delphi we have decided that this
might not necessarily be the case considering many of the core devs
(especially those that would be able to implement this) are against
this feature.
Great! I wonder whether other programming languages are bombarded in
the same way as Pascal to add foreign features which partly even
contradict its basic concept.

----------------------------------------------------------------------
VisualLab · 2023-06-19 10:14

Quote from: kupferstecher on June 19, 2023, 11:46:37 amSo the later-
assigned-const should rather be a special variable. E.g.:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i var 
MyConst: Integer; const; // can only be assigned oncebegin  Assign
MyConst := 42;  MyConst := 32; // Error: Constant variables can not be
assigned in a statement, use 'assign' instead  Assign MyConst := 32;
//Error: Dublicate initialization of constant variableend;
[hypothetical code]

If read-only variables are to be declared as in the code above, then
I'm all for this solution. You can still see that it's a variable, but
you only need to read it.

----------------------------------------------------------------------
marcov · 2023-06-19 10:15

Quote from: wp on June 19, 2023, 12:05:22 pmQuote from: PascalDragon
on June 18, 2023, 10:04:07 pmWith the introduction of inline variables
to Delphi we have decided that this might not necessarily be the case
considering many of the core devs (especially those that would be able
to implement this) are against this feature.
Great! I wonder whether other programming languages are bombarded in
the same way as Pascal to add foreign features which partly even
contradict its basic concept.

Languages like C,C++,Java and C# are managed by companies or
committees that act as stewards. Probably they have several levels of
filtering to filter out nonsense proposals, but we never see them

The fact that we allow nearly any feature request to linger
indefinitely in the bugtracker probably also plays a role.

But yes, in general it is way too much about language features, and
not other parts of the project.

The one assignment const proposal of Warfley reminds me a bit of a
comment on a discussion about micromanaging visibility of identifiers,
that eventually identifiers will need ACLs :-)

IMHO strict private is already over the top.

----------------------------------------------------------------------
VisualLab · 2023-06-19 12:27

Quote from: marcov on June 19, 2023, 12:15:26 pmIMHO strict private is
already over the top.

You mean the class scope specifiers introduced in Delphi some time
ago: strict private and strict protected? If that's what you're
talking about, then yes, it's redundant (and therefore unnecessary).

----------------------------------------------------------------------
Thaddy · 2023-06-19 12:59

Marcov's comment is a bit funny, since what the tp/Delphi designers
were trying to achieve at that moment in time with private and
protected, was actually meant to be strict private and strict
protected.
The fact that some side effects in their unit layout did not fit the
terms was basically a design flaw that later was corrected by
introducing the strict modifier.
Tying code to a class and nothing but the class or heirs is a very
good thing.
Allowing code in the same unit over different classes or variables is
a bad thing and an unwanted side effect.
(for that matter, blame it on "implementation detail". FPC devels are
rather good at that   )

----------------------------------------------------------------------
marcov · 2023-06-19 14:46

Quote from: Thaddy on June 19, 2023, 02:59:21 pmMarcov's comment is a
bit funny, since what the tp/Delphi designers were trying to achieve
at that moment in time with private and protected, was actually meant
to be strict private and strict protected.

True.

QuoteThe fact that some side effects in their unit layout did not fit
the terms was basically a design flaw that later was corrected by
introducing the strict modifier.

And two things to do nearly the same thing because of some stylistic
nitpicking is exactly what is over the top.  So by fixing one problem,
you created another that is just as bad IMHO.

----------------------------------------------------------------------
Curt Carpenter · 2023-06-19 16:42

Does this item from Marco Cantu's Object Pascal Handbook (Berlin)
reflect the current state of inline variables in Delphi, or am I
confusing two different issues?

QuoteDifferently from C and other curly-brace languages, in Object
Pascal you cannot mix variable
declarations with programming statements, but you need to group them
in specific sections (like at
the beginning of a method). Since this is not always handy, the IDE
code editor let's you actually
type the var keyword followed by the actual declaration within your
method or function code, but
it will immediately move it up to the correct position. This is one of
the predefined Live Templates,
a very nice coding helper in the IDE that you can customize and
extend.

----------------------------------------------------------------------
marcov · 2023-06-19 17:25

Quote from: Curt Carpenter on June 19, 2023, 06:42:58 pmDoes this item
from Marco Cantu's Object Pascal Handbook (Berlin) reflect the current
state of inline variables in Delphi, or am I confusing two different
issues?

Yes, you are confusing things. That is the state in Lazarus currently,
but Delphi changed after Delphi Berlin