I just had to chase an strange bug, in a local (nested) subroutine. When I made several functions (if_statement() ...) local subroutines of method statement(), they stopped to work properly :-(

After many tries I concluded, that every (recursive) invocation of the "statement" method was replaced by the "statement" result.

While it is possible to replace all occurences of "statement" by "statement()", it is not clear whether this is really the intended purpose of every occurence of "statement". This uncertainty prevents any automated refactoring of old style function code.

IMO we should have at least an option, that a function name can *not* be used for the function result any more, for the result we have the Result variable. Then we can safely distinguish between function calls (by function name) and results (by "Result"). If ever required, local functions still can refer to the result of some enclusing function, by e.g. qualified <function_name>.Result.

DoDi

I wouldn't miss not having the name of the function as a result variable in mode objfpc, at all. I think it would be a valid addition, as a compiler directive that was turned on as default, as not to break existing code

I wouldn't miss not having the name of the function as a result variable in mode objfpc, at all. I think it would be a valid addition, as a compiler directive that was turned on as default, as not to break existing code

It would break the compiler itself.

DoDi

I think for this purpose a hint is enough.

How would it? As I wrote, I suggested that you should be able to disable the function name result variable with a compiler directive. That wouldn't break anything since normal code wouldn't have the compiler directive

I know why the functionality is there, but I just think it's unnecessary baggage and complexity in a modern dialect

The semantics are really hard to figure out too, whereas it makes perfect sense when you use "result". I don't think it follows logically whether it'll call the function or set the result

I attached a patch, that works as I suggested
I think alot of other people would think of this as an unnecessary "addition", but well, I like my compilers strict :)

Can it be implemented ASAP, or is a feature request required?

DoDi

Jeppe Johansen schrieb:
[please quote inline]

It's all okay when the new directive is off, by default, or the actual compiler project options (Makefile) turn it off.

I attached a patch, that works as I suggested

Thanks, I'll check it, and possibly add it to my OO rewrite branch :-)

DoDi

In our previous episode, Jeppe Johansen said:

The semantics are really hard to figure out too, whereas it makes perfect sense when you use "result". I don't think it follows logically whether it'll call the function or set the result

Is this so? If result is a procvar, can't you call it?

Touché

But still. I don't even know how it'll be resolved. There's a function with name "functionname", and there's a variable with name "functionname"

I've stumbled into this problem a couple of times in the past, and all times it's been hard to figure out why it didn't work as intended(thought I was doing recursion, but it was just reading the result variable)

If none of the other developers refuse till tomorrow, I'll apply the patch of Jeppe.

Anybody else opinions if a hint would be better than the mode switch?

Op Wed, 28 Jul 2010, schreef Florian Klaempfl:

If I understand it well this patch will disable not only the fpc externsion:

writeln(name_of_function);

... but also the standard Pascal:

name_of_function:=value;

Why would we want to disable the standard Pascal solution? Why not disable the Borland "result" extention?

Daniël

I wouldn't accept it. It doesn't work in mode fpc. I added it here instead of the bugtracker to spark some debate in the direction

I don't think there'll be much use of it at all either, if it remains disabled by default :)

It should be implemented as a {$modeswitch xxx}, not as a special directive. Also, I think that only using result as an rvalue should be disabled by such a patch (more or less like it was the case in TP). Using the function name as an lvalue never causes an ambiguity, afaik.

Anybody else opinions if a hint would be better than the mode switch?

I think a modeswitch is fine. We have a {$modeswitch result} as well (that enables the use of the "result" identifier as alias for the function result), which can be used in e.g. FPC mode in combination with this new switch.

Jonas

Hans-Peter Diettrich wrote

Thanks, I'll check it, and possibly add it to my OO rewrite branch :-)

Just to make sure: please do not add any new features to your OO rewrite branch. Reviewing it for potential merging into trunk will be hard enough already without any new features added to it.

Jonas

TP mode can be handled differently from the other modes, never affected by this option. But this should be mentioned in the documentation, else some people may wonder why the option doesn't work in their legacy code.

DoDi

I only had added it if something prevents its use in trunk. And not now, when the OO rewrite is not yet working.

DoDi

Op Wed, 28 Jul 2010, schreef Hans-Peter Diettrich:

I wasn't talking about legacy code. I wasn't talking about TP mode either. I was talking about new code. Why not disable the "result" extension? Delphi is legacy anyway so there is no need anymore to promote its flaws.

To be clear: I am not proposing disabling the "result" extension. I'm just applying the same reasoning.

Daniël

result is non-ambigious.

Another thing: please do not commit tests inside the compiler directory. There is a separate "tests" subdirectory under the fpc repository for that, and if you did not branch that (or if the test does not belong there), then simply create your own test directory. Every unrelated change to the compiler units and/or directory makes it more laborious to merge your changes back to trunk.

Jonas

Another thing: please do not commit tests inside the compiler directory.

They are there only until the bugs have been fixed.

DoDi