[swift-evolution] Variadic generics discussion

[plx]

A few more comments inlined now that I’ve read it.

> On May 30, 2016, at 7:44 AM, plx via swift-evolution <swift-evolution at swift.org> wrote:
> - if you have e.g. 2+ packs, can you enforce (T…) and (U…) have the same arity?

Seems the answer is yes iff there’s a `T.Foo... == U.Bar…` style relationship, but no way to just request same-arity by itself?

> - if you have e.g. 2+ packs, could you enforce e.g. T.Foo… == U.Bar ?

Missed this either before or you added it, sorry either way.

> 
> …as always nice-to-have, but throwing them out there for consideration.
> 
>> I'll write something up.

I like the `fold` construct but feel like for this use it needs a few more options-or-variants.

The first one is some more-explicit support for “early exit”.

EG for the cascading-lookup example, you can convert it to this `#fold`:

  private func lookupKey(key: K) -> V? {
    return #fold(
      start: nil,
      reducer: { 
        (table, value)
        in
        return value ?? table[key]
      },
      values: tables
    )
  }

…but unless the compiler is very savvy you are going to have a bunch of unneeded stuff even after your “success” (it won’t do another lookup, but it just seems wasteful and could be wasteful in other contexts).

Relatedly, that `#fold` is only going to work if the compiler can infer a proper type for the `table` argument to the `reducer`.

If you have to specify the types explicitly via a helper function, it seems like this won’t work:

  func lookupIfNecessary<T:LookupTable where T.Key == K, T.Value == V>(table: T,  key: K, value: V?) -> V? {
     return value ?? table[key]
  }

…b/c the signature isn’t right for the reducer, and it seems like this might work:

  func createLookupFunction<T:LookupTable where T.Key == K, T.Value == V>(key: K) -> (T, V?) -> V? {
     return { (t,v) in return v ?? t[key] }
  }

  private func lookupKey(key: K) -> V? {
    return #fold(
      start: nil,
      reducer: createLookupFunction(key), // <- should work…I hope...
      values: tables
    )
  }

…but it seems a bit convoluted; perhaps there’s a trick here? Or perhaps a variant with an adjusted signature like so:

  // perhaps inout K ? or as an option?
  #foldWithContext(context: K, start: U, reducer:(#requirements,U,K) -> U, values: (T…)) -> U

Relatedly, having `#fold` variants like the above that include the current index could address a lot of the uses for integer-based indexing:

  #indexedFold(start: U, reducer:(#requirements,U,Int) -> U, values: (T…)) -> U

…(the above can be done w/out dedicated support, but dedicated support might be more compiler-friendly on this one).

Finally, after reading it over again I really find the `…` confusing beyond the initial declaration sites (as you can perhaps tell since I’ve been mis-using it in my replies).

I can’t come up with an alternative that isn’t a major regression for simple declarations, but if a more-explicit syntax could be invented I’d highly prefer it.

>> 
>>> 
>>>> On May 28, 2016, at 3:03 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> Hello 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>
> _______________________________________________
> 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/20160530/680398f0/attachment.html>