Hi Chris --
I think we've talked within the group about wanting to have cases like
this work, but (to my memory) haven't ever tackled it -- probably in part
for fear that the place where the varargs should stop matching might be
ambiguous/unclear (espcially in the face of implicit coercions and such).
Note that one might want to do similar things where the thing following x
was not a vararg itself as well. In fact, I believe we have cases
implemented today where we use name-based argument passing to supply
arguments following a varargs argument. For example, given:
proc foo(a: int...?x, b: real) { ... }
I think we have cases that call this using:
foo(b=1.2, 3, 4, 5);
or:
foo(3, 4, 5, b=1.2);
or perhaps even:
foo(3, 4, b=1.2, 5);
But yeah, I think if you can come up with a definition that supports this
cleanly and without causing too much grief in function resolution, such
support would be great and useful.
-Brad
On Thu, 12 Dec 2013, Chris Wailes wrote:
> I was playing with the following example today:
>
> proc foo(a: int ...?x, b: real ...?y) { ... }
> foo(0, 1, 2, 3.0, 4.0, 5.0);
>
> The Chapel standard doesn't say if this should or shouldn't be allowed (or
> at least I couldn't find where it said it), but the compiler fails to
> resolve the function call correctly. What does the list think? Should
> this be valid Chapel code or not?
>
> - Chris
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
