> 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 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
