This seems like a great way to do mapValues, as you get the ability to lazily map or flatMap the pairs. I’m pretty sure a key/value pair constructor is coming to Dictionary.
> On 22 May 2016, at 5:01 AM, Haravikk via swift-evolution > <[email protected]> wrote: > > >> On 21 May 2016, at 15:47, Honza Dvorsky <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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. > > 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. > > 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: > > let myTransformedDictionary = Dictionary(myIntegerDictionary.lazy.map { > ($0, $1 + 5) }) > > 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. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
