Middle-variadic method signatures, versus overloads with sequence arguments

[Renegade334]

The current draft makes heavy use of Node.js's house delicacy, middle-variadic function signatures. This necessitates some untangling in argument parsing, particularly when combined with optional arguments, and is also not expressible in the IDL, leading to the vast majority of functions having a rather ugly any... in their IDL definition.

IDL does allow for overloads, so instead of, for example,

pipeTo(source[, ...transforms], writer[, options])

one could instead have

pipeTo(source[, transforms], writer[, options])

accurately representable in the IDL as

Promise<unsigned long long> pipeTo(any source, Writer writer, optional PipeToOptions options);
Promise<unsigned long long> pipeTo(any source, sequence<any> transforms, Writer writer, optional PipeToOptions options);

This would simplify argument parsing, and is arguably more "webby".

[jasnell]

The sequence<any> changes the signatures significantly from pipeTo(source, transform1, transform2, destination) to pipeTo(source, [transform1, transform2], destination) which feels a bit more cumbersome. I'm not convinced that restricting ourselves to the limitations of WebIDL is worthwhile, but this is a point worth bringing up in committee.

[Renegade334]

IDL is one thing, but I was more thinking about argument handling primarily; this would basically cut out the need for the variadic argument parsing operations in the spec, and I think would probably make argument parsing by implementations slightly easier, although YMMV.

pull(source, transforms, options) performs...

1. ...

pull(source, options) performs...

1. Let stream be the result of calling pull(source, transforms, options) with source, an empty list, and options.
2. Return stream.