> On Jun 30, 2016, at 3:37 PM, Dave Abrahams <[email protected]> wrote:
>
>
>>>> I use it in a LazyRowSequence<T: SqlModelConvertible> where
>>>> querying Sqlite in WAL mode allows multiple concurrent readers to
>>>> get point-in-time snapshots of the database. The query can’t be
>>>> replayed without buffering all the rows in memory because Sqlite’s
>>>> step functions are not bi-directional. In some cases we are talking
>>>> about tens of thousands of rows (or even hundreds of thousands) and
>>>> the ability to avoid buffering them is a feature, not a bug.
>>
>> IMHO the typical case for single-pass is IO.
>
> Yes. Also, truly-random number generators.
>
>> In this case it would work just as well as LazyRowIterator<T> assuming
>> the language allows for-in on an iterator.
>
> So, you're not interested in using algorithms like map and filter on
> these things?
>
> If it was just about for-in, we could say you can for-in over any
> instance of
>
> ()->T?
>
Fair point; we actually do take advantage of the lazy versions of filter and
map.
Does it make sense to say that single-pass sequences are always lazy?
Iterable
/ \
/ \
LazyIterable EagerIterable
| |
LazyCollection Collection
LazyCollection is a wrapper around Collection so you can still use .lazy the
way you would today.
LazyIterables are single-pass.
EagerIterables are multi-pass.
Maybe this doesn’t work because we’re talking about somewhat orthogonal things?
I could imagine trying to model the idea of single vs multi pass and lazy vs
eager separately:
> protocol Iterable {
> associatedtype Iterator: IteratorProtocol
> associatedtype Element = Iterator.Element
> func makeIterator() -> Iterator
> }
> protocol MultiIterable: Iterable { }
> protocol SingleIterable: Iterable { }
> protocol LazyIterable: Iterable { }
> protocol EagerIterable: Iterable { }
>
> extension MultiIterable where Self: EagerIterable {
> func map<U>(t: @noescape (Element) -> U) -> [U] { }
> }
>
> extension MultiIterable where Self: LazyIterable {
> func map<U>(t: (Element) -> U) -> LazyMapMultiIterable<Self> { }
> }
>
> extension SingleIterable where Self: LazyIterable {
> func map<U>(t: (Element) -> U) -> LazyMapSingleIterable<Self> { }
> }
I guess it comes back to what you and others have pointed out - it might not be
worth the effort to provide this level of flexibility.
Russ
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
