[swift-evolution] [Pitch] Add `mapValues` method to Dictionary
Matthew Johnson
matthew at anandabits.com
Sun May 22 07:51:53 CDT 2016
Sent from my iPad
On May 22, 2016, at 1:12 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> Obviously if it's required to have a lazy variant for all collection methods, I'd probably pull back this proposal, as it would automatically be rejected by the core team.
>
> I'm not a member of the core team, but I doubt it's necessary.
>
> I don't think it makes much sense to wait for a lazy implementation. If there *is* going to be a Map protocol, then the best way to implement it will require an advanced generics feature that's still in the proposal stages:
>
> // Note: I'm simplifying signatures here.
>
> protocol Map: Collection {
> associatedtype Key
> associatedtype Value
> associatedtype Iterator: IteratorProtocol where Iterator.Element == (Key, Value)
>
> subscript (key: Key) -> Value? { get }
> func mapValues<T>(transform: Value -> T) -> [Key: T]
> }
Map should not refine Collection. We could have MapCollection (or KeyValueCollection) that refines both.
protocol Map {
associatedtype Key
associatedtype Value
subscript (key: Key) -> Value { get }
}
protocol MutableMap {
associatedtype Key
associatedtype Value
subscript (key: Key) -> Value { get set }
}
There are plenty of times where you need to be able to read from (and sometimes write to) a map without needing to know anything about how the map is implemented. A single argument function should be a valid Map (I know functions cannot conform to protocols, but I argue that they should have this ability eventually, at least protocols that only have subscript requirements).
Also note that Value *is not* Optional. There are valid maps that don't return Optional. For example, you can implement a Dictionary that takes a default value in its initializer. The function example I just gave is another example. Because Dictionary already defines a Value generic argument and returns 'Value?' From the subscript we will need to either use something clunky like MapValue (which would be 'Value?' for Dictionary) or make a change in Dictionary. But the Map protocol *should not* make the assumption that all maps are partial.
>
> And implementing the laziness will similarly work best with not only that feature, but also conditional conformances:
>
> protocol LazyMap: Map, LazyCollectionProtocol {
> subscript (key: Base.Key) -> Base.Value? { get }
> func mapValues<T>(transform: Value -> T)(…) -> LazyMappedValuesMap<Base, T>
> }
>
> extension LazyCollection: LazyMap where Base: Map {
> …
> }
>
> struct LazyMapValuesMap<Base: Map, NewValue>: Map {
> …
> }
>
> If we *don't* wait, on the other hand, we're going to end up in manual-specification and GYB hell. (And even then, I believe conditional conformances are not enough to force all LazyCollectionProtocol conformers to support Map if they have a Map base. You'd need conditional *conformance requirements*, which are *not* planned because it's not safe to add a requirement to a protocol.)
>
> I just don't think laziness is so crucial that we should stop the presses until we have it. `mapValues` carries water all by itself, even without a matching `lazy.mapValues`.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160522/23a516f0/attachment-0001.html>
More information about the swift-evolution
mailing list