Adriaan van Os wrote:
Markus Gerwinski wrote:
Bug or feature?
An interesting case indeed. Since `Result' is a Delphi feature, we probably should check if Delphi allows this, and if so do so as well.
I just tested with Delphi and found that `Result' behaves exactly like an implicitly defined local variable here. I.e. the sub-function of a function has its own `Result' that shadows the one of the enclosing function. A sub-procedure correctly accesses the `Result' of the enclosing function.
Notice, though, that if it does, it's somewhat confusing (if both `foo' and `bar' are functions, one implicit `Result' probably shadows the other -- please try this case with Delphi as well), and error-prone (in your example, if you later decide to make `bar' a function with an integer type result, the code would silently change its meaning).
Indeed. That is another advantage of the explicitly declared result variable. (At least if you, like me, prefer to avoid using the function name as a write-only identifier.)
Frank, is there any chance to change gpc's behaviour back to the way I started this thread with? I know it would violate a standard, but in this case I think the standard makes less sense than the "unwanted feature" we had before.
I agree with Frank that "Result" should behave as in Delphi and it does consistently behave there the way it was designed to, although the example shows that the whole idea of an "unnamed" Result identifier is in itself a poorly designed language feature. Obviously, not much thought went into it.
Indeed! I found out it's much worse than I thought ...
Consider the following program:
program Foo;
var Result: Integer;
function f: Integer; begin f := 1; Result := 2 end;
begin Result := 3; WriteLn (f, ' ', Result) end.
In any dialect that doesn't have a built-in `Result' (e.g. EP and even BP!), the assignment goes to the global `Result' variable, so the program writes `1 2'. (This is what GPC currently does, as well as BP.)
With Delphi, it assigns to the function result, however. So I guess it writes `2 3', does it?
So, apparently, `Result' is not just another predefined identifier of a dialect like so many others. Because it's not defined at the outermost scope, but implicitly in each function, it can in fact alter the behaviour of the same program in an incompatible way, as this example shows. This makes it a really evil feature ...
BTW, I wonder if Borland themselves noticed this straight-out incompatility between their languages, or what other more or less Borland compatible compilers do ...
So what should we do?
Up to now, we tried to handle dialects such that `--gnu-pascal' allows all dialect features combined (sometimes with warnings for particularly bad features, such as BP's "typed constants"). With `Result' this is not possible without causing incompatiblities.
The only reasonable solution I see ATM is to disable `Result' completely by default, and only enable it with `--delphi' (and a separate option which we should then probably have; `--enable-keyword=Result' won't do AFAICS since it's no keyword in Delphi, i.e. it's possible to call an identifier `Result', isn't it?; so `--enable-result' or something) ...
When it's enabled, it should, of course, be Delphi compatible then.
Frank