On 05.04.2018 8:35, Michael Van Canneyt wrote:
Now, it is also correct that the compiler developers are aware that many people rely on this implementation detail.

Since when is documented behavior considered as "implementation detail"? This is not an implementation detail. It is in official documentation.

You and I know very well that this is an implementation detail, needed
for internal bookkeeping of the compiler. That the delphi manual states
otherwise, I have always considered a grave error on their part:
It contradicts one of the core tenets of pascal - see below.

Huh, no, I don't know this is an implementation detail. For me the initialization rules always were:

1.) Global variables are initialized. (Why is simple global variables initialization needed for internal bookkeeping of the compiler?) 2.) Class fields are initialized. (Why is simple class fields initialization needed for internal bookkeeping of the compiler?)
3.) Everything else is not initialized.

Yes, I have always relied on both 1.+2. For me both points 1.+2. are well documented and wanted behavior. Isn't it so?

About point 3: your very own docs state otherwise for managed types (see my initial email in this thread) and I was surprised to read it. I am not aware the Delphi manual states anything about initializing managed types. AFAIK Delphi manual states that the compiler itself cares about memory management automatically but it doesn't state anything about when initialization or finalization must happen. It doesn't state local managed variables are initialized to empty string/nil in particular.

Until now I have never relied on implicitely initialized local variables. Your very own docs document the guaranteed local managed variable initialization, not Delphi's. If you say it is an implementation detail, you must delete it from the docs. For me the "grave error" is on FPC's side and not Delphi's.

fpc-devel maillist  -  fpc-devel@lists.freepascal.org

Reply via email to