On Mon, 10 Jun 2019, Ben Grasset wrote:
So, you're going to keep pretending like you're actually concerned about
maintaining the integrity of some (completely fictional) "traditional"
Pascal (that FPC never has been and was presumably never intended to be),
and implying that arbitrary *syntax diagrams* of all things are
non-trivially relevant to real people writing real Pascal code in real
life? Great, I guess we won't be getting anywhere productive then.
After 50 years of language extensions, I think "productivity" arguments can go
straight to where they belong: the trash can. If someone still needs extra
features to be productive, he really needs to look for another language to
program
in (or worse, another job).
So let's dispense with those arguments, please.
To the actual proposal. A recap:
The reason why you cannot do
Procedure A(B : Type definition);
as opposed to
Procedure C(D : Type Identifier);
is that the type definition for B in A only exists within the scope of A.
Whereas the type of D must exist outside of C.
So if a strict type compatibility is maintained, anything declared outside
of A will not be assignment compatible to B. (in general)
Meaning, if you were to declare
Procedure A(B : (one,two,three));
you would never be able to call this routine.
So the "rule" of not allowing to introduce new types in a procedure header
is a logical consequence of the pascal type safety.
This is a simple and easy to understand rule.
Now, there exists an exception to this rule, introduced by Borland:
open array parameters.
In a sense, a pointer definition resembles an array definition: there is a
base type. So one could make the case for allowing
procedure A(B : ^SomeType);
as an equivalent of open array parameters.
But:
We recently had a case where open array parameters and the 'ease of use'
functionality introduced around it, lead to a bug in overload resolution:
https://bugs.freepascal.org/view.php?id=35580
https://bugs.freepascal.org/view.php?id=35576
As you can see in the second bugreport the only solution was to disable the
'ease of use'
functionality.
So
1. Before embarking on implementing yet another 'ease of use' addition,
better make sure we will not again lay the foundations of hard to understand
bugs.
2. I really want to see more arguments than the worn-out 'increased productivity'
before adding another exception to an otherwise easy to understand rule in
declaring procedures/functions. Simplicity has its virtues.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
