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)
“map” already "maps the values” so I think something like “transform” might be a little clearer, if we don’t want to just overload “map”. Regardless of what it’s called, though, I’m +1 on the functionality.
- Dave Sweeris
···
On Apr 13, 2016, at 1:41 AM, Jonathan Hull via swift-evolution <swift-evolution@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.
···
on Tue Apr 12 2016, Jonathan Hull <swift-evolution@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)
------
* Only question: does this need a label, e.g.
Dictionary(uniquingKeys: d.lazy.map { (k, v) in (k, transform(v)) })
+1 for this. Highly useful method and imo should be implemented for Dictionary.
And what if we need to transform the key?
For ex. we have
var d = ["1" : "abc", "2" : "def"]
we could have such method:
d.mapKeys {k,v -> Int in Int(k)! }
to get:
[2: "abc", 1: "def"]
I.e. I suggest to implement and mapKeys() also. It could be also useful in some situations.
···
On 13.04.2016 9:41, Jonathan Hull via swift-evolution wrote:
I would really like to see something like the following added to the
standard library:
extensionDictionary{
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 like the idea of having a mapping method which maps back to the actual type.
What about a more general approach? consider:
mappedSelf(transform: T -> U) -> Self<U>
filteredSelf(includeElement: T -> Bool) -> Self<U>
Which can be added to other collections like Set and sequences like a lazy number sequence.
Best regards
- Maximilian
···
Am 13.04.2016 um 08:41 schrieb Jonathan Hull via swift-evolution <swift-evolution@swift.org>:
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.e. I suggest to implement and mapKeys() also. It could be also useful in some situations.
`mapKeys` is much more dangerous, because you could end up mapping many values into a single key. You kind of need to combine the values somehow. Perhaps: