[swift-evolution] [Pitch] Add `mapValues` method to Dictionary

[Brent Royal-Gordon]

> 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]
	}

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