Hi -
Just to be clear, I think this discussion means:
1) It would be helpful to add a more helpful error message
(like "multiple varargs are not yet supported")
2) It would also be helpful to fix expandVarArgs
so that the following program works:
proc foo(x: string..., y: int...) {
writeln("got x = ", x);
writeln("got y = ", y);
}
foo("hi", "there", 1, 2, 3);
// expect
// got x = (hi, there)
// got y = (1, 2, 3)
A few side notes...
Brad said:
> I think that we have definitely found value in putting additional
> non-varargs formals after a vararg formal as Michael illustrated --
>IIRC,
> we've had cases where we've done this and benefitted from it (though I'd
> have to dig through code to remind myself when/how). Specifically, it's
>a
> nice way to add an optional argument to an otherwise flat vararg
>function.
I used this functionality for writeln and related I/O routines.
The named argument after the varargs is the error= argument.
Rajath said:
> But, if you consider this scenario -
> vari("lions", "tigers", "bears","dogs", "cats", m=5, z=6);
> then assigning actual parameters to formal parameters is not possible.
> (unless we can set p to empty set ?)
I believe we could set p to be a zero-element tuple, yes.
For historical reasons, the Chapel compiler doesn't currently
support zero-element tuples. However, I wouldn't be surprised
if it worked to add one at this point in compilation. I believe
that we'd like to support zero-element tuples from user code too
(but that is almost certainly a larger project).
Cheers,
-michael
On 3/3/16, 1:28 PM, "Brad Chamberlain" <[email protected]> wrote:
>
>A colleague kindly reminded me of the syntax that I was grasping at in my
>last mail. Revisiting the examples I was trying to write:
>
>On Thu, 3 Mar 2016, Brad Chamberlain wrote:
>
>> proc foo(x...string, y) {
>
>Should have been written:
>
> proc foo(x: string..., y:real) {
> writeln("got x = ", x);
> writeln("got y = ", y);
> }
>
> foo("hi", "there", 3.0);
>
>And happily, this works as expected today. The second:
>
>> proc foo(x...string, y...int) {
>
>should have been written:
>
> proc foo(x: string..., y: int...) {
>
>and, unsurprisingly, this gets the same segfault as the untyped case.
>
>-Brad
>
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
