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

Sven Barth pascaldragon at googlemail.com
Tue Dec 15 22:07:19 CET 2020


Am 15.12.2020 um 20:00 schrieb Blaise at blaise.ru:
> Consider this test case:
> -------8<-------
> {$mode ObjFPC}
>
> // EXPECTED: 'Error: Identifier not found "result"'
> // ACTUAL BUG #1: gets compiled
> operator - (const L, R: Char) returned: Char;
> begin
>     result := 'Z'
> end;
>
> // EXPECTED: gets compiled
> // ACTUAL BUG #2: 'Error: Duplicate identifier "result"'
> operator / (const L, R: Char) result: Char;
> begin
>     result := 'Z'
> end;
>
> begin
> end.
> -------8<-------

No, those two are in fact correct this way.
The modeswitch Result enables the use of Result as an alias for *any* 
routine that returns a result no matter if it's an ordinary function or 
an operator and for those no matter if an explicit result name is set or 
not.
Additionally the following will fail as well (this is allowed in mode 
Delphi however):

=== code begin ===

{$mode objfpc}

function Result: LongInt;
begin
end;

begin
end.

=== code end ===

>
> The patch http://hg.blaise.ru/public/fpc/rev/ce20f68924a0 (attached) 
> alters insert_funcret_local:
> 1) Extracts duplicate code into alias_funcret;
> 2) Avoids the second call to the pd.resultname getter;
> 3) Avoids copying strings pd.resultname^/pd.procsym.name to the local 
> buffer hs;
> 4) Fixes the first bug: the alias Result should not be implicitly 
> declared when another identifier is declared as the return value;
> 5) Fixes the second bug: even with {$modeswitch result+}, it should be 
> possible to explicitly name a return value Result.
> NB: The patch preserves the current suspicious behaviour of not 
> slapping vo_is_result onto explicit names. More on that later.
>
> If needed, I can file a bug report to document the user-visible change 
> in behaviour.
>

Patch rejected as is due to the above point. If you want to address 1) 
to 3) you can do so however.

vo_is_result is only set on the Result alias by design (search for 
vo_is_result and you'll see a few locations where vo_is_result is 
checked while vo_is_funcret is not).

Also please use { ... } for comments, not // ...

Regards,
Sven


More information about the fpc-devel mailing list