Correct me if I'm wrong, but isn't part of the goal of lazy collections to be able to prefix a whole chain of operations with .lazy and have it still compile (and be more efficient)? If so, then the core team would probably want both variants in the standard library.<br><div class="gmail_quote"><div dir="ltr">On Sat, May 21, 2016 at 12:16 PM Honza Dvorsky via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I see your point, I agree it would definitely be nicer to have both variants, but is that a rule that *all* methods on Collection and Dictionary etc also have lazy variants? I actually don't know (please tell me if you do).<div><br></div><div>The question here is not really whether to add a lazy variant later (I don't think anyone would object to that), but as that would require quite substantial refactoring and abstraction change into a Map protocol (which will definitely gather a lot of feedback and could drag on for months), I don't see why we can't add the regular variant already and benefit from it now. Another option is that there won't be demand for the lazy variant, in which case it makes even less sense to block the regular variant right now (and could even hurt this proposal).</div><div><br></div><div>Maybe I'm missing some information about the core team requiring always adding both non-lazy and lazy variants, if so, please do tell me so that I can re-evaluate my approach. If not, I'd like to keep the thread focused strictly on the one method I'm proposing we add, for the benefits and examples I provided.</div><div><br></div><div>The Dictionary initializers could slightly help things, but it'd require nesting if you do more than one level, whereas `mapValues` would allow for multiple transformations to be applied in sequence without additional nesting (my example from the original pitch would turn into `var descriptionTextLengths = Dictionary(Dictionary(repos.mapValues { $0["description"].string }).mapValues { $0.characters.count })` which is much uglier in my opinion (and kind of breaks the natural left-to-right composition).</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, May 21, 2016 at 8:01 PM Haravikk <<a href="mailto:swift-evolution@haravikk.me" target="_blank">swift-evolution@haravikk.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 21 May 2016, at 15:47, Honza Dvorsky <<a href="mailto:jan.dvorsky@me.com" target="_blank">jan.dvorsky@me.com</a>> wrote:</div><br><div><div dir="ltr">While I agree that it'd be nice to add a Map abstraction into which we could move a lot of the Dictionary-ness, my original pitch is *just* about adding the specific implementation of `mapValues` in its regular, non-lazy form. My example was about only keeping a subset of the information in memory in a Dictionary to allow for quick and frequent access (lazy goes against that). I think it'd be better to get that in first, or at least evaluate that separately from a comprehensive refactoring of the Dictionary, which would just accumulate more opinions and slow this specific step down.</div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>Sorry, my point was that I think it’s better to wait until we can also do the lazy equivalent and have both done together, otherwise we end up with one map function that can work both lazily and one that never does. Sure that will require a refactoring into a protocol, but it seems to me that it’s better to do that as the first step, then add the feature after that. In the mean time extensions have you well covered for convenience.</div><div><br></div><div>Another alternative to this feature might be to add a key/value pair constructor to Dictionary (it technically already has one, but it’s variadic only) so you could do something like this:</div><div><br></div><div><font face="Monaco"><span style="white-space:pre-wrap"> </span>let myTransformedDictionary = Dictionary(myIntegerDictionary.lazy.map { ($0, $1 + 5) })</font></div><div><br></div><div>Since this would be a useful initialiser both now and in future. I dunno, it’s just my opinion, but I find it a bit weird to get half the implementation now, and could lead to misunderstandings with people trying to do myMap.lazy.mapValues (won’t be recognised) and wondering why there isn’t one.</div></div></blockquote></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr"><div><div>Dan Appel<br></div></div></div>