A few more comments inlined now that I’ve read it.
> On May 30, 2016, at 7:44 AM, plx via swift-evolution
> <[email protected]> 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
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> Hello swift-evolution,
>>>>
>>>
>>> _______________________________________________
>>> 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] <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
