From a90d3e5be1c7e70ba3904a1c3d6e3a1b45c4bc7d Mon Sep 17 00:00:00 2001 From: Diana Ma Date: Fri, 2 Jan 2026 20:09:19 +0000 Subject: [PATCH 1/7] Efficient `Dictionary.mapValues` with key context --- .../NNNN-dictionary-mapvalues-with-keys.md | 114 ++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 proposals/NNNN-dictionary-mapvalues-with-keys.md diff --git a/proposals/NNNN-dictionary-mapvalues-with-keys.md b/proposals/NNNN-dictionary-mapvalues-with-keys.md new file mode 100644 index 0000000000..c2acccafb6 --- /dev/null +++ b/proposals/NNNN-dictionary-mapvalues-with-keys.md @@ -0,0 +1,114 @@ +# Efficient `Dictionary.mapValues` with key context + +* Proposal: [SE-NNNN](NNNN-dictionary-mapvalues-with-keys.md) +* Authors: [Diana Ma](https://github.com/tayloraswift) (tayloraswift) +* Review Manager: unassigned +* Status: **Pitch** +* Implementation: [#86268](https://github.com/swiftlang/swift/pull/86268) +* Review: ([pitch](https://forums.swift.org/t/giving-dictionary-mapvalues-access-to-the-associated-key/83904)) + +## Introduction + +I propose adding an overload to `Dictionary.mapValues` (and `OrderedDictionary.mapValues`) that passes the `Key` to the transformation closure. + +This enables us to transform dictionary values with their associated key context without incurring the performance cost of rehashing (or in the case of `reduce`, reallocating) the dictionary storage, which is currently unavoidable when using `init(uniqueKeysWithValues:)` or `reduce(into:)`. + +## Motivation + +Currently, when it is necessary to compute the mapped dictionary value using the dictionary key, we must do one of the following: + +```swift +let new: [Key: NewValue] = .init( + uniqueKeysWithValues: old.lazy.map { ($0, transform(id: $0, payload: $1)) } +) +// or +let new: [Key: NewValue] = old.reduce(into: [:]) { + $0[$1.key] = transform(id: $1.key, payload: $1.value) +} +``` + +These are both highly pessimized patterns due to expensive hashing, although benchmarks frequently show that the first one is slightly “less bad” than the second one due to having fewer intermediate reallocations. + +Although users occasionally also want to [transform dictionary keys](https://forums.swift.org/t/mapping-dictionary-keys/15342), this proposal is focused on the use case where dictionary keys are never modified and are only used to provide context (such as aggregation parameters) that is not part of the payload values. + +## Proposed solution + +I propose adding the following overload to `Dictionary`: + +```swift +extension Dictionary { + @inlinable public func mapValues( + _ transform: (Key, Value) throws -> T + ) rethrows -> Dictionary +} + +``` + +And similarly for `OrderedDictionary` in `swift-collections`: + +```swift +extension OrderedDictionary { + @inlinable public func mapValues( + _ transform: (Key, Value) throws -> T + ) rethrows -> OrderedDictionary +} + +``` + +### Usage example + +```swift +let balances: [Currency: Int64] = [.USD: 13, .EUR: 15] +let displayText: [Currency: String] = balances.mapValues { + "\($0.alpha3) balance: \($1)" +} +``` + +## Detailed design + +### Changes to `Dictionary` + +The implementation would mirror the existing `(Value) -> T` overload of `mapValues` but inside the storage iteration loop it would pass the key along with the value to the transformation closure. + +On Apple platforms, `Dictionary` may be backed by a Cocoa dictionary. This does not pose any major issues, as `__CocoaDictionary` can be retrofitted with essentially the same machinery as `_NativeDictionary` within the standard library, and the new `mapValues` can dispatch between the two exactly as the existing `mapValues` does. + +### Changes to `OrderedDictionary` (swift-collections) + +The performance gain for `OrderedDictionary` could be even more significant. `OrderedDictionary` maintains a standard `Array` for keys and values, plus a sidecar hash table for lookups. + +The current workaround (`reduce` or `init`) forces the reconstruction of the entire hash table and an eager copy of the keys array. We could instead: + +1. use zipped iteration to map the underlying `_keys` and `_values` arrays to a new array of values, +1. copy the `_keys` array, which is an O(1) copy-on-write if not mutated, or O(*n*) on later mutation, and +1. copy the `_hashTable` buffer directly, which is also a lazy copy-on-write operation. + +## Source compatibility + +This is an ABI and API-additive change. + +Type inference will handle the overloading gracefully based on the closure’s arity: + +```swift +dictionary.mapValues { v in ... } // selects existing `(Value) -> T` +dictionary.mapValues { k, v in ... } // selects new `(Key, Value) -> T` + +``` + +## Alternatives considered + +### Alternative naming + +I considered selecting a new name, such as `mapPairs` or `mapContextual`, to avoid overload resolution complexity. But Swift generally prefers overloading when the semantics – mapping values while preserving structure – remain identical. + +### Additional overload for `compactMapValues` + +The new `mapValues` overload would introduce an API asymmetry with `compactMapValues`, which would not support key context. I believe this is justified, as `compactMapValues` is essentially a shorthand for calling `reduce(into:)`, which makes the performance aspect considerably less motivating. + +### Doing nothing + +As an extensively frozen type, it may be possible for developers to retrofit `Dictionary` in user space to support key context by relying on stable-but-unspecified implementation details. Similarly, the `swift-collections` package could be forked to add such functionality. But this would not be a good workflow and we should not encourage it. + + +## Future directions + +The proposed `mapValues` overload does not use typed `throws`, for symmetry with the existing overload. Both overloads could be mirrored with typed `throws` variants in the future. From be0f6c9d787a49f9fc0cb9ba6397f69f458661e4 Mon Sep 17 00:00:00 2001 From: Diana Ma Date: Fri, 2 Jan 2026 21:13:39 +0000 Subject: [PATCH 2/7] link swift-collections implementation --- proposals/NNNN-dictionary-mapvalues-with-keys.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/NNNN-dictionary-mapvalues-with-keys.md b/proposals/NNNN-dictionary-mapvalues-with-keys.md index c2acccafb6..f015369d44 100644 --- a/proposals/NNNN-dictionary-mapvalues-with-keys.md +++ b/proposals/NNNN-dictionary-mapvalues-with-keys.md @@ -4,7 +4,7 @@ * Authors: [Diana Ma](https://github.com/tayloraswift) (tayloraswift) * Review Manager: unassigned * Status: **Pitch** -* Implementation: [#86268](https://github.com/swiftlang/swift/pull/86268) +* Implementation: [`#86268`](https://github.com/swiftlang/swift/pull/86268), [`swift-collections:#556`](https://github.com/apple/swift-collections/pull/556) * Review: ([pitch](https://forums.swift.org/t/giving-dictionary-mapvalues-access-to-the-associated-key/83904)) ## Introduction From ca39699be928f6379ad2735559f0bf48aa0b2ef5 Mon Sep 17 00:00:00 2001 From: Diana Ma Date: Fri, 2 Jan 2026 21:23:39 +0000 Subject: [PATCH 3/7] be more precise about OrderedDictionary implementation --- proposals/NNNN-dictionary-mapvalues-with-keys.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/proposals/NNNN-dictionary-mapvalues-with-keys.md b/proposals/NNNN-dictionary-mapvalues-with-keys.md index f015369d44..86aae0d88a 100644 --- a/proposals/NNNN-dictionary-mapvalues-with-keys.md +++ b/proposals/NNNN-dictionary-mapvalues-with-keys.md @@ -76,11 +76,7 @@ On Apple platforms, `Dictionary` may be backed by a Cocoa dictionary. This does The performance gain for `OrderedDictionary` could be even more significant. `OrderedDictionary` maintains a standard `Array` for keys and values, plus a sidecar hash table for lookups. -The current workaround (`reduce` or `init`) forces the reconstruction of the entire hash table and an eager copy of the keys array. We could instead: - -1. use zipped iteration to map the underlying `_keys` and `_values` arrays to a new array of values, -1. copy the `_keys` array, which is an O(1) copy-on-write if not mutated, or O(*n*) on later mutation, and -1. copy the `_hashTable` buffer directly, which is also a lazy copy-on-write operation. +The current workaround (`reduce` or `init`) forces the reconstruction of the entire hash table and an eager copy of the keys array. We could instead use zipped iteration to map the underlying `_keys` and `_values` arrays to a new array of values, and then copy the `_keys` table – which includes the hash table `__storage` – and is an O(1) copy-on-write if not mutated, or O(*n*) on later mutation. ## Source compatibility From bc2cd9a81047f5a7cd4e610c10f5a1a9ba0083d0 Mon Sep 17 00:00:00 2001 From: Diana Ma Date: Mon, 5 Jan 2026 17:29:32 +0000 Subject: [PATCH 4/7] mapValuesWithKeys --- .../NNNN-dictionary-mapvalues-with-keys.md | 42 ++++++++----------- 1 file changed, 17 insertions(+), 25 deletions(-) diff --git a/proposals/NNNN-dictionary-mapvalues-with-keys.md b/proposals/NNNN-dictionary-mapvalues-with-keys.md index 86aae0d88a..cecceab053 100644 --- a/proposals/NNNN-dictionary-mapvalues-with-keys.md +++ b/proposals/NNNN-dictionary-mapvalues-with-keys.md @@ -1,15 +1,15 @@ -# Efficient `Dictionary.mapValues` with key context +# Introduce `Dictionary.mapValuesWithKeys` * Proposal: [SE-NNNN](NNNN-dictionary-mapvalues-with-keys.md) * Authors: [Diana Ma](https://github.com/tayloraswift) (tayloraswift) * Review Manager: unassigned * Status: **Pitch** * Implementation: [`#86268`](https://github.com/swiftlang/swift/pull/86268), [`swift-collections:#556`](https://github.com/apple/swift-collections/pull/556) -* Review: ([pitch](https://forums.swift.org/t/giving-dictionary-mapvalues-access-to-the-associated-key/83904)) +* Review: ([pitch](https://forums.swift.org/t/giving-dictionary-mapvalues-access-to-the-associated-key/83904)) ## Introduction -I propose adding an overload to `Dictionary.mapValues` (and `OrderedDictionary.mapValues`) that passes the `Key` to the transformation closure. +I propose adding a method `Dictionary.mapValuesWithKeys` (and `OrderedDictionary.mapValuesWithKeys`) that passes the `Key` to the transformation closure. This enables us to transform dictionary values with their associated key context without incurring the performance cost of rehashing (or in the case of `reduce`, reallocating) the dictionary storage, which is currently unavoidable when using `init(uniqueKeysWithValues:)` or `reduce(into:)`. @@ -20,10 +20,10 @@ Currently, when it is necessary to compute the mapped dictionary value using the ```swift let new: [Key: NewValue] = .init( uniqueKeysWithValues: old.lazy.map { ($0, transform(id: $0, payload: $1)) } -) +) // or -let new: [Key: NewValue] = old.reduce(into: [:]) { - $0[$1.key] = transform(id: $1.key, payload: $1.value) +let new: [Key: NewValue] = old.reduce(into: [:]) { + $0[$1.key] = transform(id: $1.key, payload: $1.value) } ``` @@ -33,11 +33,11 @@ Although users occasionally also want to [transform dictionary keys](https://for ## Proposed solution -I propose adding the following overload to `Dictionary`: +I propose adding the following method to `Dictionary`: ```swift extension Dictionary { - @inlinable public func mapValues( + @inlinable public func mapValuesWithKeys( _ transform: (Key, Value) throws -> T ) rethrows -> Dictionary } @@ -48,7 +48,7 @@ And similarly for `OrderedDictionary` in `swift-collections`: ```swift extension OrderedDictionary { - @inlinable public func mapValues( + @inlinable public func mapValuesWithKeys( _ transform: (Key, Value) throws -> T ) rethrows -> OrderedDictionary } @@ -59,7 +59,7 @@ extension OrderedDictionary { ```swift let balances: [Currency: Int64] = [.USD: 13, .EUR: 15] -let displayText: [Currency: String] = balances.mapValues { +let displayText: [Currency: String] = balances.mapValuesWithKeys { "\($0.alpha3) balance: \($1)" } ``` @@ -68,9 +68,9 @@ let displayText: [Currency: String] = balances.mapValues { ### Changes to `Dictionary` -The implementation would mirror the existing `(Value) -> T` overload of `mapValues` but inside the storage iteration loop it would pass the key along with the value to the transformation closure. +The implementation would mirror the existing `mapValues` method but inside the storage iteration loop it would pass the key along with the value to the transformation closure. -On Apple platforms, `Dictionary` may be backed by a Cocoa dictionary. This does not pose any major issues, as `__CocoaDictionary` can be retrofitted with essentially the same machinery as `_NativeDictionary` within the standard library, and the new `mapValues` can dispatch between the two exactly as the existing `mapValues` does. +On Apple platforms, `Dictionary` may be backed by a Cocoa dictionary. This does not pose any major issues, as `__CocoaDictionary` can be retrofitted with essentially the same machinery as `_NativeDictionary` within the standard library, and the new `mapValuesWithKeys` can dispatch between the two exactly as the existing `mapValues` does. ### Changes to `OrderedDictionary` (swift-collections) @@ -82,29 +82,21 @@ The current workaround (`reduce` or `init`) forces the reconstruction of the ent This is an ABI and API-additive change. -Type inference will handle the overloading gracefully based on the closure’s arity: - -```swift -dictionary.mapValues { v in ... } // selects existing `(Value) -> T` -dictionary.mapValues { k, v in ... } // selects new `(Key, Value) -> T` - -``` - ## Alternatives considered ### Alternative naming -I considered selecting a new name, such as `mapPairs` or `mapContextual`, to avoid overload resolution complexity. But Swift generally prefers overloading when the semantics – mapping values while preserving structure – remain identical. +The original draft of this proposal planned on overloading the existing `mapValues` method to accept a closure that takes both `Key` and `Value`. This was discovered to be source-breaking in rare scenarios where `mapValues` was being called on a dictionary with a 2-tuple value type. Thus, the new name `mapValuesWithKeys` was chosen to avoid source compatibility issues. -### Additional overload for `compactMapValues` +### Additional companion method for `compactMapValues` -The new `mapValues` overload would introduce an API asymmetry with `compactMapValues`, which would not support key context. I believe this is justified, as `compactMapValues` is essentially a shorthand for calling `reduce(into:)`, which makes the performance aspect considerably less motivating. +The new `mapValuesWithKeys` method would introduce an API asymmetry with `compactMapValues`, which would not support key context. I believe this is justified, as `compactMapValues` is essentially a shorthand for calling `reduce(into:)`, which makes the performance aspect considerably less motivating. -### Doing nothing +### Doing nothing As an extensively frozen type, it may be possible for developers to retrofit `Dictionary` in user space to support key context by relying on stable-but-unspecified implementation details. Similarly, the `swift-collections` package could be forked to add such functionality. But this would not be a good workflow and we should not encourage it. ## Future directions -The proposed `mapValues` overload does not use typed `throws`, for symmetry with the existing overload. Both overloads could be mirrored with typed `throws` variants in the future. +The proposed `mapValuesWithKeys` method does not use typed `throws`, for symmetry with the existing API. Both methods could be mirrored with typed `throws` variants in the future. From 3c62f3bbf50a5a94be510b2fcd74149b548aa27c Mon Sep 17 00:00:00 2001 From: Diana Ma Date: Sun, 1 Feb 2026 22:18:08 +0000 Subject: [PATCH 5/7] update text --- .../NNNN-dictionary-mapvalues-with-keys.md | 55 ++++++++++--------- 1 file changed, 30 insertions(+), 25 deletions(-) diff --git a/proposals/NNNN-dictionary-mapvalues-with-keys.md b/proposals/NNNN-dictionary-mapvalues-with-keys.md index cecceab053..392343c3be 100644 --- a/proposals/NNNN-dictionary-mapvalues-with-keys.md +++ b/proposals/NNNN-dictionary-mapvalues-with-keys.md @@ -4,12 +4,12 @@ * Authors: [Diana Ma](https://github.com/tayloraswift) (tayloraswift) * Review Manager: unassigned * Status: **Pitch** -* Implementation: [`#86268`](https://github.com/swiftlang/swift/pull/86268), [`swift-collections:#556`](https://github.com/apple/swift-collections/pull/556) +* Implementation: [`#86268`](https://github.com/swiftlang/swift/pull/86268) * Review: ([pitch](https://forums.swift.org/t/giving-dictionary-mapvalues-access-to-the-associated-key/83904)) ## Introduction -I propose adding a method `Dictionary.mapValuesWithKeys` (and `OrderedDictionary.mapValuesWithKeys`) that passes the `Key` to the transformation closure. +I propose adding a method `Dictionary.mapValuesWithKeys` that passes the `Key` to the transformation closure. This enables us to transform dictionary values with their associated key context without incurring the performance cost of rehashing (or in the case of `reduce`, reallocating) the dictionary storage, which is currently unavoidable when using `init(uniqueKeysWithValues:)` or `reduce(into:)`. @@ -37,20 +37,9 @@ I propose adding the following method to `Dictionary`: ```swift extension Dictionary { - @inlinable public func mapValuesWithKeys( - _ transform: (Key, Value) throws -> T - ) rethrows -> Dictionary -} - -``` - -And similarly for `OrderedDictionary` in `swift-collections`: - -```swift -extension OrderedDictionary { - @inlinable public func mapValuesWithKeys( - _ transform: (Key, Value) throws -> T - ) rethrows -> OrderedDictionary + @inlinable public func mapValuesWithKeys( + _ transform: (Key, Value) throws(E) -> T + ) throws(E) -> Dictionary } ``` @@ -64,19 +53,13 @@ let displayText: [Currency: String] = balances.mapValuesWithKeys { } ``` -## Detailed design -### Changes to `Dictionary` +## Detailed design The implementation would mirror the existing `mapValues` method but inside the storage iteration loop it would pass the key along with the value to the transformation closure. On Apple platforms, `Dictionary` may be backed by a Cocoa dictionary. This does not pose any major issues, as `__CocoaDictionary` can be retrofitted with essentially the same machinery as `_NativeDictionary` within the standard library, and the new `mapValuesWithKeys` can dispatch between the two exactly as the existing `mapValues` does. -### Changes to `OrderedDictionary` (swift-collections) - -The performance gain for `OrderedDictionary` could be even more significant. `OrderedDictionary` maintains a standard `Array` for keys and values, plus a sidecar hash table for lookups. - -The current workaround (`reduce` or `init`) forces the reconstruction of the entire hash table and an eager copy of the keys array. We could instead use zipped iteration to map the underlying `_keys` and `_values` arrays to a new array of values, and then copy the `_keys` table – which includes the hash table `__storage` – and is an O(1) copy-on-write if not mutated, or O(*n*) on later mutation. ## Source compatibility @@ -94,9 +77,31 @@ The new `mapValuesWithKeys` method would introduce an API asymmetry with `compac ### Doing nothing -As an extensively frozen type, it may be possible for developers to retrofit `Dictionary` in user space to support key context by relying on stable-but-unspecified implementation details. Similarly, the `swift-collections` package could be forked to add such functionality. But this would not be a good workflow and we should not encourage it. +As an extensively frozen type, it may be possible for developers to retrofit `Dictionary` in user space to support key context by relying on stable-but-unspecified implementation details. But this would not be a sound workflow and we should not encourage it. ## Future directions -The proposed `mapValuesWithKeys` method does not use typed `throws`, for symmetry with the existing API. Both methods could be mirrored with typed `throws` variants in the future. +### Adoption of typed `throws` for pre-existing methods + +The proposed `mapValuesWithKeys` method uses typed `throws`, unlike the existing `mapValues` method which uses untyped `throws`. In the future, we may wish to introduce a typed `throws` variant of `mapValues` as well, and take the API break opportunity to select a new name for this method, which would then enable the standard library to eventually reassign the `mapValues` name to the version that supplies key context to the transformation closure. + +### Changes to `OrderedDictionary` (swift-collections) + +As a natural extension of this proposal, the `OrderedDictionary` type in the `swift-collections` package could also gain a `mapValuesWithKeys` method with similar performance benefits. + +It would have the following signature: + + +```swift +extension OrderedDictionary { + @inlinable public func mapValuesWithKeys( + _ transform: (Key, Value) throws(E) -> T + ) throws(E) -> OrderedDictionary +} + +``` + +The performance gain for `OrderedDictionary` could be even more significant than for `Dictionary`. `OrderedDictionary` maintains a standard `Array` for keys and values, plus a sidecar hash table for lookups. The current workaround (`reduce` or `init`) forces the reconstruction of the entire hash table and an eager copy of the keys array. We could instead use zipped iteration to map the underlying `_keys` and `_values` arrays to a new array of values, and then copy the `_keys` table – which includes the hash table `__storage` – and is an O(1) copy-on-write if not mutated, or O(*n*) on later mutation. + +For completeness, I have provided a draft implementation in a PR to the `swift-collections` repository: [`swift-collections:#556`](https://github.com/apple/swift-collections/pull/556). From 93bd37be0ed8ab5cdcefd3b2f140d859f1929bbe Mon Sep 17 00:00:00 2001 From: Diana Ma Date: Mon, 2 Feb 2026 18:22:32 +0000 Subject: [PATCH 6/7] mapValues rename --- proposals/NNNN-dictionary-mapvalues-with-keys.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/proposals/NNNN-dictionary-mapvalues-with-keys.md b/proposals/NNNN-dictionary-mapvalues-with-keys.md index 392343c3be..46f040cd47 100644 --- a/proposals/NNNN-dictionary-mapvalues-with-keys.md +++ b/proposals/NNNN-dictionary-mapvalues-with-keys.md @@ -82,9 +82,9 @@ As an extensively frozen type, it may be possible for developers to retrofit `Di ## Future directions -### Adoption of typed `throws` for pre-existing methods +### Reassigning the name `mapValues` -The proposed `mapValuesWithKeys` method uses typed `throws`, unlike the existing `mapValues` method which uses untyped `throws`. In the future, we may wish to introduce a typed `throws` variant of `mapValues` as well, and take the API break opportunity to select a new name for this method, which would then enable the standard library to eventually reassign the `mapValues` name to the version that supplies key context to the transformation closure. +In the future, we may wish to rename the existing `mapValues` method to something like `mapValuesWithoutKeys`, which would enable the standard library to reassign the `mapValues` name to the version that supplies key context to the transformation closure in a subsequent language mode. ### Changes to `OrderedDictionary` (swift-collections) @@ -99,7 +99,6 @@ extension OrderedDictionary { _ transform: (Key, Value) throws(E) -> T ) throws(E) -> OrderedDictionary } - ``` The performance gain for `OrderedDictionary` could be even more significant than for `Dictionary`. `OrderedDictionary` maintains a standard `Array` for keys and values, plus a sidecar hash table for lookups. The current workaround (`reduce` or `init`) forces the reconstruction of the entire hash table and an eager copy of the keys array. We could instead use zipped iteration to map the underlying `_keys` and `_values` arrays to a new array of values, and then copy the `_keys` table – which includes the hash table `__storage` – and is an O(1) copy-on-write if not mutated, or O(*n*) on later mutation. From 1fb2a5bd2716c02fa70234809c5248b3284a1e6a Mon Sep 17 00:00:00 2001 From: Stephen Canon Date: Tue, 3 Feb 2026 16:20:19 -0500 Subject: [PATCH 7/7] Update and rename NNNN-dictionary-mapvalues-with-keys.md to 0510-dictionary-mapvalues-with-keys.md --- ...es-with-keys.md => 0510-dictionary-mapvalues-with-keys.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename proposals/{NNNN-dictionary-mapvalues-with-keys.md => 0510-dictionary-mapvalues-with-keys.md} (97%) diff --git a/proposals/NNNN-dictionary-mapvalues-with-keys.md b/proposals/0510-dictionary-mapvalues-with-keys.md similarity index 97% rename from proposals/NNNN-dictionary-mapvalues-with-keys.md rename to proposals/0510-dictionary-mapvalues-with-keys.md index 46f040cd47..5f84174a6b 100644 --- a/proposals/NNNN-dictionary-mapvalues-with-keys.md +++ b/proposals/0510-dictionary-mapvalues-with-keys.md @@ -1,8 +1,8 @@ # Introduce `Dictionary.mapValuesWithKeys` -* Proposal: [SE-NNNN](NNNN-dictionary-mapvalues-with-keys.md) +* Proposal: [SE-0510](NNNN-dictionary-mapvalues-with-keys.md) * Authors: [Diana Ma](https://github.com/tayloraswift) (tayloraswift) -* Review Manager: unassigned +* Review Manager: [Steve Canon](https://github.com/stephentyrone) * Status: **Pitch** * Implementation: [`#86268`](https://github.com/swiftlang/swift/pull/86268) * Review: ([pitch](https://forums.swift.org/t/giving-dictionary-mapvalues-access-to-the-associated-key/83904))