[swift-evolution] swift-evolution Digest, Vol 5, Issue 35

[Terrence Katzenbaer]

+1 for initializer over mapValues. One downside is that it’s impossible or very difficult to find documentation for Swift types (e.g. Dictionary) using Google, but I don’t think that this should impede considering this implementation.

-1 for god methods. My concern is probably trivial but... if having a parameter that takes a closure to deal with key conflicts is an absolute necessity, then I propose it being optional or having an version of the initializer without it.

> Message: 22
> Date: Sun, 17 Apr 2016 06:58:23 -0700
> From: Jonathan Hull <jhull at gbis.com>
> To: swift-evolution <swift-evolution at swift.org>
> Cc: dabrahams at apple.com
> Subject: Re: [swift-evolution] [Proposal] mapValues
> Message-ID: <BEF0657E-BCAD-4AFA-A035-6E3D92B7A58B at gbis.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 
> I am definitely +1 for adding the initializer in any case.  
> 
> I would like to see it (based on Nate’s suggestion) have a “merge" parameter which takes a closure of (Key, Value, Value)throws->Value, which would be called to choose a value whenever a repeated key is encountered.  That parameter should have a default value which just traps.  That way the default behavior is to trap when a key is repeated, but it can still be overridden with a more appropriate behavior for the situation (e.g. keeping the first value, keeping the last, averaging them, etc…)
> 
> That said, I would still also like to see the functionality of mapValues (whatever it ends up being called) in the standard library.  It easily applies to 80-90% of my use cases, and allowing re-mapping of keys adds a lot of complexity which must be carefully considered (there is a lot more which can go wrong).  As swift is a practical language, it would be nice to have a quick and foolproof way to do this common task.
> 
> Thanks,
> Jon
> 
> 
>> on Tue Apr 12 2016, Jonathan Hull <swift-evolution at swift.org <https://lists.swift.org/mailman/listinfo/swift-evolution>> 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.