[fpc-devel] Explicitly named return values and implicit aliases Result

Sven Barth pascaldragon at googlemail.com
Wed Dec 16 11:26:16 CET 2020

Blaise--- via fpc-devel <fpc-devel at lists.freepascal.org> schrieb am Mi.,
16. Dez. 2020, 10:14:

> > The modeswitch Result enables the use of Result as an alias for *any*
> routine …
> Incorrect. The identifier Result does not alias the routine, it aliases
> the routine's return value.

For non operators the routine's name *is* the name of the return variable.

> > … that returns a result no matter if an explicit result name is set or
> not.
> I maintain that such approach is an orthogonality violation. In light that
> FPC provides a syntax for explicitly naming the return value, the
> consistent and conceptually simplest way to treat Result as the
> implicit/default name for that value, not as an alias to a name that cannot
> even be specified in most cases (non-operators).

For non operators the name of the real result value *is* the name of the
routine and Result is the alias. Operators don't have names (in the
classical sense, internally they have one of course), thus for the modes
without Result modeswitch a way had to be introduced to specify the name of
the variable containing the result.

> Were the presented cases examined when the current behaviour was
> implemented? And, if so, what were the points defending it? Does anyone
> actually think that there is even one good theoretical or practical reason
> to reject the following?

I doubt that was examined back then, but right now the behavior is
consistent and I see no need to change it.

> Additionally the following will fail as well (this is allowed in mode
> Delphi however):
> > function Result: LongInt;
> That is not quite relevant for this discussion. A function and its return
> value are different entities.

Yes, it is relevant for this discussion, because it's the same piece of
code in the compiler that handles this.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20201216/2d3460c9/attachment-0001.htm>

More information about the fpc-devel mailing list