> On Jun 1, 2016, at 8:29 AM, Joe Groff <[email protected]> wrote:
> 
>> 
>> On Jun 1, 2016, at 6:26 AM, Matthew Johnson <[email protected]> wrote:
>> 
>>> 
>>> On Jun 1, 2016, at 8:18 AM, Joe Groff via swift-evolution 
>>> <[email protected]> wrote:
>>> 
>>>> 
>>>> On May 31, 2016, at 6:49 PM, Austin Zheng <[email protected]> wrote:
>>>> 
>>>> I agree that this is a better design for Swift than the monstrosity I 
>>>> started out with.
>>>> 
>>>> The "biggest" technical challenge I see is being able to type a reduction 
>>>> sort of operator on a heterogenous tuple based on on whatever protocols 
>>>> and constraints are common to its constituent members. For example:
>>>> 
>>>> // Every Tn in T... is Fooable and Barrable
>>>> let x : (T...)
>>>> reduce(x, reducer, startingValue)
>>>> 
>>>> func reducer<X : ???>(startingValue: U, eachMemberOfT: X) -> U { ... }
>>>> 
>>>> How do we bound ??? such that 'reducer' is useful while still being 
>>>> statically type sound? Honestly, that's the most interesting question to 
>>>> me. Generalized existentials might help with that.
>>> 
>>> If every T is Fooable and Barrable, couldn't `eachMemberOfT` be (inout U, 
>>> protocol<Fooable, Barrable>) -> ()?
>>> 
>>>> Other questions (inherent to any proposal) would be:
>>>> 
>>>> - How do we resolve the impedance mismatch between tuples and function 
>>>> argument lists? Is it even worth trying to resolve this mismatch, given 
>>>> that argument lists are intentionally not intended to mirror tuples?
>>> 
>>> The impedance mismatch between function arguments and tuples is 
>>> superficial. You ought to be able to splat and bind tuples into function 
>>> arguments, e.g.:
>>> 
>>>     let args = (1, 2)
>>>     foo(bar:bas:)(args...)
>>> 
>>>     func variadicFn<T: Runcible...>(_ args: T...) { … }
>> 
>> Going this direction is relatively straightforward.  The impedance mismatch 
>> is trickier when you want to do more than that.  For example, it would be 
>> extremely useful to come up with some way to wrap a function that has 
>> parameters with default arguments without requiring callers of the wrapped 
>> function to supply arguments for the defaulted parameters.  Any ideas on how 
>> to solve that?
> 
> As Chris noted, that sounds like a great use case for a macro. Trying to do 
> that with the type system feels like it's on the wrong side of the complexity 
> threshold to me.

Makes sense.  Looking forward to having macros someday… :)

> 
> -Joe
> 
>>> 
>>>> - As you said, how do variadic generics work in the 0- and 1-member cases?
>>> 
>>> What problem are you referring to?
>>> 
>>> -Joe
>>> 
>>> _______________________________________________
>>> 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

Reply via email to