The problem with treating them as Collection
or more accurately RandomAccessCollection
is that the Iterator
would need to have some sort of annotation of the return type of next that permits the heterogeneous type signature that may be applied. Consider a pack of Numeric
things: that could be Int
, Int32
, Int8
and so on. The iterator would need to have some way of addressing that return type to be different per iteration call. Maybe some
types might work?
It would be reasonable however to still access a pack in an indexed fashion. I have distinct need for this behavior for similar APIs to zip
.
One could easily conceive of count being implemented as:
func count<T...>(_ items: T...) -> Int {
var count = 0
for _ in items { count += 1 }
return count
}
But more complex algorithms need some more distinct access: for example making a combinatoric of states:
Lets say you have some types that are operations:
protocol Operation {
associatedtype Output
func run() async -> Output
}
Then you want to pass a variadic of operations into a structure and for each call invoke the output resultant of that operation that happened next out of the group. This means there are a few different states associated with that - they all could be idle, the first could be actively running in a task and the rest could be idle, the second could be actively running and the others would be idle and so on, and then the final state is terminal.
Given a non variadic situation I would write this as for two items as an enum as such:
enum State {
case allIdle(Operation1, Operation2)
case firstPending(Task<Operation1.Output, Never>, Operation2)
case secondPending(Operation1, Task<Operation2.Output, Never>)
case terminal
}
The proposal as such does not seem to address this type of usage. Indexable packs might be able to allow for this type of affordance (perhaps with a downside of some states that are unreachable).
In that same vein of "higher kinded type" variadics - if the example of zip was to store elements for asynchronous processing of a temporary; would there be a way to map types across?
Say I needed to store the iterators and some values to compose the resultant. How can I map the type of the pack of iterators to a pack of corresponding Iterator.Element
?
From what I can tell this does not allow for that - which seems like a missing part that still poses me reaching for .gyb
files.