Sign in to follow this  

Bug with parsing of callable expressions

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

void f()
{
arr[0]();
}
[/code]

The same issue happens here:
[code]
F@ g()
{
return null;
}

void f()
{
g()();
}
[/code]

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

Share this post


Link to post
Share on other sites
[quote name='Andreas Jonsson' timestamp='1341326274' post='4955315']
funcdefs are automatically shared as long as all types (arguments and return value) are shared.
[/quote]
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this