<div dir="ltr">Please correct me if I'm off here, but I quickly looked at the implementation of lazy collections/sequences, and I think it's because the goal is to keep the API of e.g. normal Array and a lazy Array the same, so that you don't actually have to know which one you're working with. But under the hood, they're very different objects, as one owns the memory of its elements, whereas the lazy one goes back to the array it was created with and pulls it elements (before e.g. transforming them). And as structs cannot be subclassed, a lot of the functionality is implemented in default functions on the protocol. So if you wanted to create a lazy version of a Dictionary, which has an identical API, you'd have to duplicate a lot of code - unless you pull the Dictionary-ness into a protocol, make Dictionary just the normal form of Dictionary, but allow a LazyDictionary under the hood to pull values from a parent dictionary based on keys, transform them with mapValues and return them.<div><br></div><div>Does that make sense? I looked at the implementation of Dictionary in the stdlib yesterday, and IMO it'd be a pretty huge amount of work to refactor it into the Map protocol first, so I'm trying to push for having a non-lazy version done first, and then add the lazy version once someone proposes to add the Map protocol later (otherwise this'll just get stuck here for months, because I doubt the core team would be happy with making such large changes for allowing one convenience method only, now that Swift 3 is being stabilized).<div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, May 22, 2016 at 7:48 AM Dan Appel <<a href="mailto:dan.appel00@gmail.com">dan.appel00@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't understand - why do we need a map protocol for a lazy mapvalues? <br><div class="gmail_quote"><div dir="ltr">On Sat, May 21, 2016 at 11:12 PM Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> 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.<br>
<br>
I'm not a member of the core team, but I doubt it's necessary.<br>
<br>
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:<br>
<br>
// Note: I'm simplifying signatures here.<br>
<br>
protocol Map: Collection {<br>
associatedtype Key<br>
associatedtype Value<br>
associatedtype Iterator: IteratorProtocol where Iterator.Element == (Key, Value)<br>
<br>
subscript (key: Key) -> Value? { get }<br>
func mapValues<T>(transform: Value -> T) -> [Key: T]<br>
}<br>
<br>
And implementing the laziness will similarly work best with not only that feature, but also conditional conformances:<br>
<br>
protocol LazyMap: Map, LazyCollectionProtocol {<br>
subscript (key: Base.Key) -> Base.Value? { get }<br>
func mapValues<T>(transform: Value -> T)(…) -> LazyMappedValuesMap<Base, T><br>
}<br>
<br>
extension LazyCollection: LazyMap where Base: Map {<br>
…<br>
}<br>
<br>
struct LazyMapValuesMap<Base: Map, NewValue>: Map {<br>
…<br>
}<br>
<br>
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.)<br>
<br>
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`.<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr"><div><div>Dan Appel<br></div></div></div>
</blockquote></div>