> On May 31, 2016, at 5:29 PM, Matthew Johnson <[email protected]> wrote: > > >>> On May 31, 2016, at 10:17 AM, L Mihalkovic <[email protected]> >>> wrote: >>> >>> >>>> On May 31, 2016, at 4:26 PM, Matthew Johnson <[email protected]> >>>> wrote: >>>> >>>> >>>>> 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]> 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 >>> ? >>> >>> 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 >>> >> >> 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. > >> >>> >>>> >>>> >>>>> Matthew >>>>> >>>>>> On May 29, 2016, at 7:36 PM, Austin Zheng via swift-evolution >>>>>> <[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]> 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 >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
