> On May 31, 2016, at 9:16 AM, L Mihalkovic <[email protected]> > wrote: > > > >> On May 31, 2016, at 3:57 PM, Matthew Johnson via swift-evolution >> <[email protected] <mailto:[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.
Are you talking about providing conditional conformance in a protocol extension: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions> ? That is not what I was talking about. I was talking about extensions of structural types: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#extensions-of-structural-types> > > >> 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 >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
