> Obviously if it's required to have a lazy variant for all collection methods,
> I'd probably pull back this proposal, as it would automatically be rejected
> by the core team.
I'm not a member of the core team, but I doubt it's necessary.
I don't think it makes much sense to wait for a lazy implementation. If there
*is* going to be a Map protocol, then the best way to implement it will require
an advanced generics feature that's still in the proposal stages:
// Note: I'm simplifying signatures here.
protocol Map: Collection {
associatedtype Key
associatedtype Value
associatedtype Iterator: IteratorProtocol where
Iterator.Element == (Key, Value)
subscript (key: Key) -> Value? { get }
func mapValues<T>(transform: Value -> T) -> [Key: T]
}
And implementing the laziness will similarly work best with not only that
feature, but also conditional conformances:
protocol LazyMap: Map, LazyCollectionProtocol {
subscript (key: Base.Key) -> Base.Value? { get }
func mapValues<T>(transform: Value -> T)(…) ->
LazyMappedValuesMap<Base, T>
}
extension LazyCollection: LazyMap where Base: Map {
…
}
struct LazyMapValuesMap<Base: Map, NewValue>: Map {
…
}
If we *don't* wait, on the other hand, we're going to end up in
manual-specification and GYB hell. (And even then, I believe conditional
conformances are not enough to force all LazyCollectionProtocol conformers to
support Map if they have a Map base. You'd need conditional *conformance
requirements*, which are *not* planned because it's not safe to add a
requirement to a protocol.)
I just don't think laziness is so crucial that we should stop the presses until
we have it. `mapValues` carries water all by itself, even without a matching
`lazy.mapValues`.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
