[fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

[Michael Van Canneyt]

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.