> On May 31, 2016, at 3:57 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > Austin, > > One very useful possibility opened up by variadic generics that you don’t > mention is the ability to write extensions for structural types (tuple, > function, maybe union in the future), including conforming them to protocols. > This would be a separate proposal building on the capability of variadic > generics but might be worth mentioning in “future directions”. >
It might be worth reading again the generics manifesto’s comment about how the runtime cost of chasing up the protocol chain might turn it into a performance nightmare. > Matthew > >> On May 29, 2016, at 7:36 PM, Austin Zheng via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> I significantly rewrote the proposal to take into account as much feedback >> as I could. (Many things, like syntax, haven't been changed yet, but will be >> in a forthcoming version.) >> >> What I did change: >> >> - Renamed 'packs' to 'vectors' >> - Discussed variadic typealiases a bit, including things like "variadic >> String" for holding the results of vector computations >> - There's a "every variadic associated type must be equal" constraint that >> can be defined now >> - I added a section discussing a "fold" operation, to reduce a value >> pack/value vector into a single scalar with the help of a user-defined >> function. >> - I changed the proposal so that making a tuple out of a vector now requires >> surrounding the vector with #tuple(), to get rid of the 'implicit' rules >> that plx brought up >> - I added a section briefly discussing how this feature might be implemented. >> >> Some thoughts: >> >> - Things like indexing into a value vector by an integer value would be >> extremely powerful. But as far as I can tell they'd require a great deal of >> macro-like functionality to go along with them. A way to define constant >> expressions would be required, so we could define "#index = #count(T...)" or >> something. Then we'd need ways to manipulate that value (increment or >> decrement) if we wanted to work with the previous or next elements in a >> chain, we'd need compile-time conditional checking so that a variadic >> generic could behave correctly for the first or last item in a vector, and >> so forth. Omitting these expensive features is going to limit the number of >> uses variadic generics have; is this tradeoff going to be worth it? Could we >> push off those features to a later date, if/when Swift gets an actual >> compile time metaprogramming design? >> >> - The more I think about things, the more I'm leaning towards the idea that >> tuples are the only construct necessary. We could get rid of most of the >> features of value packs/vectors, and allow them to only serve two roles: >> defining a variadic generic function, and spreading out a tuple in order to >> call a variadic generic function. (I think I prefer a spreading operator to >> bringing back the magic compiler tuple splat functionality.) They could also >> be "spread out" to define or specialize a different variadic generic type. >> Thoughts? >> >> - With the existence of 'fold', might it be worth it to remove #tail() (and >> maybe #head), at least from v1? This would represent a slight loss of >> expressive power for common use cases in exchange for a considerable >> decrease in complexity. >> >> Alternatively, some tuple-based designs might make this point obsolete. >> Imagine something like this: >> >> func head<T, ...U>(input: (T, U...)) -> T { ... } >> func tail<T, ...U>(input: (T, U...)) -> (U...) { ... } >> >> Again, any comments are welcome. I hope to continue evolving this proposal >> as the community decides what they want and don't want to see. >> >> >>> On May 28, 2016, at 1:03 PM, Austin Zheng <[email protected] >>> <mailto:[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: >>> >>> 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 >>> >>> 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> >>> >>> Feedback would be greatly appreciated. Again, be unsparing. >>> >>> Best, >>> Austin >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > 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
