> On May 31, 2016, at 10:46 AM, L. Mihalkovic <[email protected]> > wrote: > > > > On May 31, 2016, at 5:29 PM, Matthew Johnson <[email protected] > <mailto:[email protected]>> wrote: > >> >>> On May 31, 2016, at 10:17 AM, L Mihalkovic <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> On May 31, 2016, at 4:26 PM, Matthew Johnson <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On May 31, 2016, at 9:16 AM, L Mihalkovic <[email protected] >>>>> <mailto:[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> >>>> >>> >>> the two sections are linked. My point is just to keep in mind what they say >>> about the conformances that can be established at compile time, versus the >>> scenarios that wind-up hitting the runtime reflection system to resolve a >>> question (dynamic casts). >> >> There are no performance concerns noted in Doug’s manifesto. Extensions, >> including conformances for structural types is listed under “minor >> extensions”, not “maybe” or “unlikely”. Providing extensions and >> conformances for structural types shouldn’t be any more difficult than doing >> so for any other variadic type. > > Good... my moment of doubt came from reading the code involved in the > differed initialization og metadata for the case of non fixed size tuples. I > will play more with the compiler and see if I can trigger it.
It sounds like you’re more familiar with the implementation than I am. I don’t know how much work has been done to support general variadic types yet. It’s possible there is still a lot of work to be done. But I can’t imagine any reason variadic conformance would be more difficult for built-in structural types than it is for user-defined variadic 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
