[swift-evolution] [Proposal] mapValues

Dave Abrahams dabrahams at apple.com
Wed Apr 13 13:50:10 CDT 2016


on Tue Apr 12 2016, Jonathan Hull <swift-evolution at swift.org> wrote:

> I would really like to see something like the following added to the standard
> library:
>
> extension Dictionary {
>
> func mapValues<U>(transform:(Key,Value)->U)->[Key:U] {
> var output:[Key:U] = [:]
> for (k,v) in self {
> output[k] = transform(k,v)
> }
> return output
> }
>
> }
>
> It comes up enough that I have had to add it to pretty much every one of my
> projects. I also don’t feel comfortable adding it to my frameworks, since I
> figure a lot of people are also adding something like this to their projects,
> and I don’t want to cause a conflict with their version. Prime candidate for the
> standard library.
>
> I like calling it ‘mapValues' as opposed to providing an override for map, since
> it makes the specific behavior more clear. I would expect ‘map' to possibly map
> the keys as well (though there are issues where the new keys overlap). I suppose
> you could just have a bunch of overrides for map if the compiler becomes good
> enough at differentiating return types: (Value)->(Value), (Key,Value)->Value,
> (Key, Value)->(Key,Value)

I agree that we need a way to do this, and was surprised when what I
tried didn't work.  This should work:

  Dictionary(d.lazy.map { (k, v) in (k, transform(v)) })

We should have a proposal that makes the constructor work* if we don't
already have one.

I'm inclined against building specialized variants of basic algorithms
into particular collections, though.  Could be talked out of it if the
use-case is strong enough.

------

* Only question: does this need a label, e.g. 

    Dictionary(uniquingKeys: d.lazy.map { (k, v) in (k, transform(v)) })

  to denote that it's lossy?
-- 
Dave



More information about the swift-evolution mailing list