[fpc-pascal] SetLength warnings - request

[Jonas Maebe]

On 2018-12-31 02:54, Martok wrote:
>> There is a hint for such parameters even though the compiler knows 
>> they
>> always contain a valid value, because valid in the sense of "won't 
>> crash
>> the program" is not the same as "this is what the programmer 
>> intended".
> 
> Are you baiting me, or was that accidental? ;-)

I'm 100% serious about the above. Code should be explicit, not implicit. 
It's up to the compiler to remove unnecessary code based on what it 
knows is implicitly guaranteed. The programmer should only have to focus 
on the algorithms and on making their code as explicit/clear as 
possible. Removing initialisations based on the type of variables (which 
then may have to be re-added in case the type or usage changes) does not 
help with that.

In that sense, the optimisation capabilities of a compiler are quite 
important for the quality of the code that people write, because a 
better optimiser means that (some) people are less inclined to mangle 
their code and "tune" it to implementation details in order to coax the 
compiler into generating the code they want to see.

>> 1) Dynamic arrays are initialised with nil, but that is an
>> implementation detail
> 
> Is it, though? Global variables and instance fields are zero-filled, 
> local
> variables as if the local variable block was a record passed to 
> Initialize()
> (so, recursively zeroing managed fields). Although it is never spelled 
> out, the
> Delphi manual heavily implies this.
> I would guess most if not all pascal programmers wrote code that relies 
> on that
> at some point.

Yes, and that indeed would make it very hard to change any of that 
without breaking any code. The fact that people rely on implementation 
details does not make them any less of an implementation detail. In this 
context, "detail" does not mean "less significant fact or item" but 
"individual fact or item".

In general, the Turbo/Borland/Free Pascal community is very bad in terms 
of relying on implementation details. This is normal if you only have 
one dominant compiler. It's the same for individual companies (= 
mini-communities) that only use e.g. Visual C++ or GCC.

> @MvC: I'll come up with some examples and add it to the Portability 
> page, since
> the different result variable initialization rules already are a bit
> of an issue.

Since such code will also give wrong results in Delphi under certain 
circumstances (which most Delphi programmers probably don't know, 
because usually string result variables _are_ indeed nil there), this is 
a perfect illustration of my first point. Especially since unless you 
are clairvoyant, it is impossible to know that your function will never 
be used in the future in a way that will cause the result to be 
non-empty from the start.


Jonas