[swift-evolution] Variadic generics discussion

Tue May 31 10:29:34 CDT 2016

> On May 31, 2016, at 10:17 AM, L Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
> 
>> 
>> On May 31, 2016, at 4:26 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>> 
>>> On May 31, 2016, at 9:16 AM, L Mihalkovic <laurent.mihalkovic at gmail.com <mailto:laurent.mihalkovic at gmail.com>> wrote:
>>> 
>>> 
>>> 
>>>> On May 31, 2016, at 3:57 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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.

> 
>> 
>>> 
>>> 
>>>> Matthew
>>>> 
>>>>> On May 29, 2016, at 7:36 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> 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
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160531/0236870c/attachment.html>