[swift-evolution] [Proposal] Variadics as Attribute

[Haravikk]

> On 20 Jul 2016, at 21:25, Leonardo Pessoa <me at lmpessoa.com> wrote:
> 
> I'm strongly opposed to this too. I'm not only not fond of the
> proposed syntax but I also don't really see how allowing other types
> in variadics will help anything. Also, there may be necessary more
> complex code to support all the extra (or even previously unknown)
> types that could be used with this syntax, making the language much
> more complex.


First; the proposal isn't specifically about enabling other types, I put it in its own section as it's not the primary goal, just a potential bonus now or in future. The main goal is having one function declaration syntax, rather than a feature-specific syntax that creates a need for a type of secondary function, it's about merging the two; so hopefully actually simplifying things in reality by turning variadics into a feature of any function, rather than its own sort of separate thing.

Second, I don't believe it should be overly complex at all; remember all a variadic function really is is a function taking an array, except you don't need to add square brackets. That's basically what it boils down to; it's a way of calling a function such that you can pretend the values you are passing in are arguments, when really they're not. Extending with more types shouldn't really add complexity as they already work with regular functions right now, and I think I've covered the requirements already (a fixed type needs to conform to ArrayLiteralConvertible, while a generic must be able to match an Array).

> On 20 Jul 2016, at 21:40, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I'm also having trouble getting behind this proposal.
> 
> IMO, variadics as implemented today in Swift (and in Java) are a subset of the problems that can be solved with variadic generics. They're more limited because you can't today support heterogeneous argument lists without losing static type information by forcing all values to be a less-specific type (like Any, in the worst case).
> 
> Given that Swift will (hopefully) support variadic generics in the future, I'd love to see the current variadic syntax/implementation go away entirely and be reïmplemented using variadic generics instead. The solution proposed here is too specific given that possible future and I think it's more of a lateral move with few benefits rather than an incremental move that gets the language toward a greater goal.

Can you be more specific about what you mean by variadic generics? Why do you feel these are incompatible with this proposal? The proposal's core after all is about using a single style of function declaration then turning on the ability to call in the variadic style via an attribute, so it seems like it'd be a first step towards most other alternatives anyway IMO as either you use a different attribute to enable the feature, or some kind of generic type to match what you want it to accept.

> Considering the set of problems where one would like to support both an inline variadic homogeneous argument list syntax *or* splatting in a collection, I think that set is small enough that a special syntax isn't necessary. I would consider an API that *only* supports homogeneous variadic arguments a poorly designed API, and we shouldn't add complexity to the language to support that; we should encourage API authors to write versions that take collections instead, and if they really want to support variadics, implement it in terms of the collection-taking method.
> 
> I'm also of the opinion that for most use cases involving homogeneous argument lists, having to add the two characters "[" and "]" around the arguments is not a significant burden to end users.

As I briefly mention at the end of the proposal I'm originally in the ditch variadics entirely camp, as like you I don't see the big deal with just adding square brackets and being explicit about the type. This proposal is intended in part as a compromise, since a lot of people seem to like them.