Frank Heckenbach wrote:
Markus Gerwinski wrote:
compiling the program
Program Test;
var x: integer;Function foo: integer;
Procedure bar; begin (* bar *) result:= 7; end (* bar *);begin (* foo *) bar; end (* foo *);
begin x:= foo; end.
yields an error message
test.pas: In procedure `bar': test.pas:14: error: invalid access to `Result' test.pas: In function `foo': test.pas:20: error: result of function not assigned
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.
Yours,
Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193