ambiguous behaviour: optional parameter after `varargs` of the same type has unclear behaviour

[Luyten-Orion]

Optional parameter T after a varargs T doesn't have clear semantics in how it's defined.

Example

proc test(a: varargs[string], b = "") =
  echo "a=", a
  echo "b=", b

test("hello")
test("hello", "world", "!")

Actual Output

a=["hello"]
b=
a=["hello", "world"]
b=!

Expected Output

Not too sure...

Possible Solution

In my opinion, emitting a warning that says something along the lines "optional T after varargs T will cause the last argument of type T to be passed to the optional parameter!"

Additional Information

References

[zerbina]

varargs being underspecified is a known issue, and there's an in-progress PR for specifying the feature: #1207.

The PR specifies that the only way to pass a value to a trailing parameter with a default (when there's preceding varargs) is to use named parameter passing.

A related issue (varargs being followed by varargs): #1375.

[Luyten-Orion]

gotcha, should i close this issue then?

…

On Thu, 19 Jun 2025, 12:46 am zerbina, ***@***.***> wrote: *zerbina* left a comment (nim-works/nimskull#1556) <#1556 (comment)> varargs being underspecified is a known issue, and there's an in-progress PR for specifying the feature: #1207 <#1207>. The PR specifies that the only way to pass a value to a trailing parameter with a default (when there's preceding varargs) is to use named parameter passing. A related issue (varargs being followed by varargs): #1375 <#1375>. — Reply to this email directly, view it on GitHub <#1556 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BGSGUV5476OQKWK5WCVJPB33EH25BAVCNFSM6AAAAAB7UOAHDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOBWGA2TQMJZGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[zerbina]

No no, it's good that there's an issue, as the issue should be a little easier to discover and search for than the PR. Sorry for the confusion.