# Bug with parsing of callable expressions

This topic is 2255 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Revision 1289. This code gives a parsing error, "Expected ';'" at the line with arr[0]().
 funcdef void F(); array<F@> arr; void f() { arr[0](); } 

The same issue happens here:
 F@ g() { return null; } void f() { g()(); } 

Speaking of funcdefs, Is it possible to allow them to be shared? Edited by Andreas Jonsson

##### Share on other sites
Thanks. I have definitely not predicted these scenarios. I'll work on the necessary changes.

funcdefs are automatically shared as long as all types (arguments and return value) are shared.

Regards,
Andreas

##### Share on other sites

funcdefs are automatically shared as long as all types (arguments and return value) are shared.

That is good to know. I was just assuming that like everything else they are specific to the module. What is the expected behaviour if two modules declare funcdefs with the same name, but different signatures (and let's say that all arguments and the return value are shared)? I ask that in the light of that undocumented feature you mentioned once, with shared objects being ignored by the compiler after their first declaration.

##### Share on other sites
In this case each module will only see their own funcdef.

When checking if a matching funcdef exists, the engine compares all types and name and only if everything matches are they said to be the same type.

Perhaps it would be more consistent to require the declaration with 'shared' in order to match funcdefs from a different module, but so far I don't really see a problem with leaving it the way it is.

##### Share on other sites
I've implemented the support for this in revision 1368.

Regards,
Andreas

##### Share on other sites
How feasible is it looking to add a function-call operator, given the new development?

(Pardon if this is tangental to the topic at hand; for the uninformed, Andreas remarked that this change would be involve of the work prerequisite to function-call operators.) Edited by cellulose

##### Share on other sites
I don't think it will be too difficult. Basically the compiler needs to be modified in the same places where the function pointer is handled, so that when the expression is not a function pointer the compiler instead checks if it is an object with available methods named 'opCall'. If it is then the argument list should be evaluated and the right overload chosen just like a normal function call.

1. 1
2. 2
3. 3
Rutin
18
4. 4
JoeJ
14
5. 5

• 14
• 10
• 23
• 9
• 32
• ### Forum Statistics

• Total Topics
632630
• Total Posts
3007521
• ### Who's Online (See full list)

There are no registered users currently online

×