> On May 28, 2016, at 3:03 PM, Austin Zheng via swift-evolution > <[email protected]> wrote: > > Hello swift-evolution, > > I put together a draft proposal for the variadic generics feature described > in "Completing Generics" as a major objective for Swift 3.x. It can be found > here:
Austin, this is really exciting! Thank you very much for all of the work you’re doing on “Completing Generics”. These features are at the very top of my list of desired features in Swift. > > https://github.com/austinzheng/swift-evolution/blob/az-variadic-generics/proposals/XXXX-variadic-generics.md > > <https://github.com/austinzheng/swift-evolution/blob/az-variadic-generics/proposals/XXXX-variadic-generics.md> > > It adopts the syntax and semantics that are described in Completing Generics, > and attempts to remain as simple as possible while still being useful for > certain use cases (although I think there is still room to simplify). The > proposal contains sample implementations for four use cases: > > - Arbitrary-arity 'zip' sequence > - Arbitrary-arity tuple comparison for equality > - Tuple splat/function application > - Multiple-arity Clojure-style 'map’ function These are some very good and clearly articulated examples. Great work! This section is important because variadics are somewhat complicated and it is important to show people why we want them and what problems they can solve. > > There is a lot of scope for design refinements, and even for alternative > designs. With enhanced existentials, there was already an informal consensus > that the feature would involve composing some protocols and class > requirements, and placing constraints on the associated types, and most > everything else was working out the various implications of doing so. That's > not true for this feature. > > In particular, I'm interested to see if there are similarly expressive > designs that use exclusively tuple-based patterns and no parameter packs. I > think Rust once considered a similar approach, although their proposal ended > up introducing a parameter-pack like construct for use with fn application: > https://github.com/rust-lang/rfcs/issues/376 > <https://github.com/rust-lang/rfcs/issues/376> As far as I can tell, the way you are approaching `apply` would not allow the default arguments of the function passed as `function` to be used when calling `apply`. Arguments would have to be provided for all parameters when the function is invoked through apply. I know that this difficulty is not directly related to variadic generics, but it does demonstrate a limitation of this approach to forwarding. I have already run into a use case where I would like to accept a function and a pack of arguments, store the arguments, be able to compare them for equality, and later invoke the function with them. However, in order for this approach to make sense in my use case it would be essential that the user *not* need to explicitly provide arguments for parameters with defaults. I bring this up in hopes that we might try to explore designs that would support this use case, and at least give it some consideration. I’m trying to think of ways to make this work but haven’t come up with anything obvious yet. -Matthew > > Feedback would be greatly appreciated. Again, be unsparing. > > Best, > Austin > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
