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.
Still - what about adding a warning when "Result" is referenced in the subprocedure (or sub-subprocedure) of a function ?
Regards,
Adriaan van Os