+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 <[email protected]> > To: swift-evolution <[email protected]> > Cc: [email protected] > Subject: Re: [swift-evolution] [Proposal] mapValues > Message-ID: <[email protected]> > 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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
