[Pitch] Make Optional, Array, and Dictionary conditionally Equatable

Douglas_Gregor · November 22, 2017, 6:50am

Hi all,

We’re having a bit of a debate <https://github.com/apple/swift/pull/12910> over the question of whether SE-0143 “Conditional Conformances” <https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md> actually proposes any standard library changes at all, or whether they should all be brought up separately. So, I’ll pitch the pieces that I’d love to put into 4.1 to see if they’re as obvious as I think they should be

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary conform to Equatable when their type parameters are Equatable (and Set always conform to Equatable). Specifically, add to the standard library:

  extension Optional: Equatable where Wrapped: Equatable { /*== already exists */ }
  extension Array: Equatable where Element: Equatable { /*== already exists */ }
  extension ArraySlice: Equatable where Element: Equatable { /*== already exists */ }
  extension ContiguousArray: Equatable where Element: Equatable { /*== already exists */ }
  extension Dictionary: Equatable where Value: Equatable { /*== already exists */ }
  extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a highly-requested feature and an obvious “first use” of conditional conformances for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?

- Doug

Chris_Lattner · November 22, 2017, 5:48pm

IMO this is obvious and you should put it in.

The process serves a purpose: to ensure the evolution of the language is going in the right place, both directionally in an details. It is obvious that we’re going to take this, and the details are clear, therefore doing an evolution cycle for this would just waste everyone’s time.

That said, when you get to less obvious introductions and start doing more major consolidation and simplification of the stdlib, those changes may be worthy of discussion to ensure the details are right.

-Chris

···

On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

We’re having a bit of a debate <https://github.com/apple/swift/pull/12910> over the question of whether SE-0143 “Conditional Conformances” <https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md> actually proposes any standard library changes at all, or whether they should all be brought up separately. So, I’ll pitch the pieces that I’d love to put into 4.1 to see if they’re as obvious as I think they should be

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary conform to Equatable when their type parameters are Equatable (and Set always conform to Equatable). Specifically, add to the standard library:

  extension Optional: Equatable where Wrapped: Equatable { /*== already exists */ }
  extension Array: Equatable where Element: Equatable { /*== already exists */ }
  extension ArraySlice: Equatable where Element: Equatable { /*== already exists */ }
  extension ContiguousArray: Equatable where Element: Equatable { /*== already exists */ }
  extension Dictionary: Equatable where Value: Equatable { /*== already exists */ }
  extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a highly-requested feature and an obvious “first use” of conditional conformances for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

davedelong · November 22, 2017, 6:12pm

The reason these are on concrete types and not, say, Collection is because we can’t conditionally conform protocols yet, right?

Dave

···

On Nov 21, 2017, at 11:51 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

We’re having a bit of a debate <https://github.com/apple/swift/pull/12910> over the question of whether SE-0143 “Conditional Conformances” <https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md> actually proposes any standard library changes at all, or whether they should all be brought up separately. So, I’ll pitch the pieces that I’d love to put into 4.1 to see if they’re as obvious as I think they should be :)

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary conform to Equatable when their type parameters are Equatable (and Set always conform to Equatable). Specifically, add to the standard library:

  extension Optional: Equatable where Wrapped: Equatable { /*== already exists */ }
  extension Array: Equatable where Element: Equatable { /*== already exists */ }
  extension ArraySlice: Equatable where Element: Equatable { /*== already exists */ }
  extension ContiguousArray: Equatable where Element: Equatable { /*== already exists */ }
  extension Dictionary: Equatable where Value: Equatable { /*== already exists */ }
  extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a highly-requested feature and an obvious “first use” of conditional conformances for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?

anandabits · November 22, 2017, 5:55pm

Seems like a no-brainer to me. If there has been any argument against making this change I am really curious to know what it is. I’m super excited that this might make it into 4.1. Woohoo!!!

···

On Nov 22, 2017, at 12:51 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

We’re having a bit of a debate <https://github.com/apple/swift/pull/12910> over the question of whether SE-0143 “Conditional Conformances” <https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md> actually proposes any standard library changes at all, or whether they should all be brought up separately. So, I’ll pitch the pieces that I’d love to put into 4.1 to see if they’re as obvious as I think they should be

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary conform to Equatable when their type parameters are Equatable (and Set always conform to Equatable). Specifically, add to the standard library:

  extension Optional: Equatable where Wrapped: Equatable { /*== already exists */ }
  extension Array: Equatable where Element: Equatable { /*== already exists */ }
  extension ArraySlice: Equatable where Element: Equatable { /*== already exists */ }
  extension ContiguousArray: Equatable where Element: Equatable { /*== already exists */ }
  extension Dictionary: Equatable where Value: Equatable { /*== already exists */ }
  extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a highly-requested feature and an obvious “first use” of conditional conformances for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Karl · November 22, 2017, 5:26pm

I think they’re supposed to be brought up separately. There are actually a few areas of the standard library that have become outdated as we accepted new language features without corresponding proposals about using them. For example, we have top-level SetIndex and DictionaryIndex typealiases and SetIterator and DictionaryIterator types; dinosaurs from the era before nested generics.

As for this proposal? +1. Obviously.

- Karl

···

On 22. Nov 2017, at 07:51, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

We’re having a bit of a debate <https://github.com/apple/swift/pull/12910> over the question of whether SE-0143 “Conditional Conformances” <https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md> actually proposes any standard library changes at all, or whether they should all be brought up separately. So, I’ll pitch the pieces that I’d love to put into 4.1 to see if they’re as obvious as I think they should be

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary conform to Equatable when their type parameters are Equatable (and Set always conform to Equatable). Specifically, add to the standard library:

  extension Optional: Equatable where Wrapped: Equatable { /*== already exists */ }
  extension Array: Equatable where Element: Equatable { /*== already exists */ }
  extension ArraySlice: Equatable where Element: Equatable { /*== already exists */ }
  extension ContiguousArray: Equatable where Element: Equatable { /*== already exists */ }
  extension Dictionary: Equatable where Value: Equatable { /*== already exists */ }
  extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a highly-requested feature and an obvious “first use” of conditional conformances for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Douglas_Gregor · November 22, 2017, 6:08pm

IMO this is obvious and you should put it in.

The process serves a purpose: to ensure the evolution of the language is going in the right place, both directionally in an details. It is obvious that we’re going to take this, and the details are clear, therefore doing an evolution cycle for this would just waste everyone’s time.

I’ve been leaning this way as well. We can treat this small addition as an amendment to SE-0143 so the change is documented appropriately.

That said, when you get to less obvious introductions and start doing more major consolidation and simplification of the stdlib, those changes may be worthy of discussion to ensure the details are right.

Right. All of the consolidation of the various Slice and lazy types is big enough to warrant a proposal, for example.

- Doug

···

Sent from my iPhone

On Nov 22, 2017, at 9:48 AM, Chris Lattner <clattner@nondot.org> wrote:

-Chris

On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

We’re having a bit of a debate over the question of whether SE-0143 “Conditional Conformances” actually proposes any standard library changes at all, or whether they should all be brought up separately. So, I’ll pitch the pieces that I’d love to put into 4.1 to see if they’re as obvious as I think they should be

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary conform to Equatable when their type parameters are Equatable (and Set always conform to Equatable). Specifically, add to the standard library:

  extension Optional: Equatable where Wrapped: Equatable { /*== already exists */ }
  extension Array: Equatable where Element: Equatable { /*== already exists */ }
  extension ArraySlice: Equatable where Element: Equatable { /*== already exists */ }
  extension ContiguousArray: Equatable where Element: Equatable { /*== already exists */ }
  extension Dictionary: Equatable where Value: Equatable { /*== already exists */ }
  extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a highly-requested feature and an obvious “first use” of conditional conformances for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Douglas_Gregor · November 22, 2017, 6:28pm

Hi all,

We’re having a bit of a debate over the question of whether SE-0143 “Conditional Conformances” actually proposes any standard library changes at all, or whether they should all be brought up separately. So, I’ll pitch the pieces that I’d love to put into 4.1 to see if they’re as obvious as I think they should be

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary conform to Equatable when their type parameters are Equatable (and Set always conform to Equatable). Specifically, add to the standard library:

  extension Optional: Equatable where Wrapped: Equatable { /*== already exists */ }
  extension Array: Equatable where Element: Equatable { /*== already exists */ }
  extension ArraySlice: Equatable where Element: Equatable { /*== already exists */ }
  extension ContiguousArray: Equatable where Element: Equatable { /*== already exists */ }
  extension Dictionary: Equatable where Value: Equatable { /*== already exists */ }
  extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a highly-requested feature and an obvious “first use” of conditional conformances for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?

The reason these are on concrete types and not, say, Collection is because we can’t conditionally conform protocols yet, right?

Right. SE-0143 has a discussion of this limitation.

- Doug

···

Sent from my iPhone

On Nov 22, 2017, at 10:12 AM, Dave DeLong <swift@davedelong.com> wrote:

On Nov 21, 2017, at 11:51 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Dave

trs · November 22, 2017, 7:38pm

+1

-Thorsten

···

Am 22.11.2017 um 18:48 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:

IMO this is obvious and you should put it in.

The process serves a purpose: to ensure the evolution of the language is going in the right place, both directionally in an details. It is obvious that we’re going to take this, and the details are clear, therefore doing an evolution cycle for this would just waste everyone’s time.

That said, when you get to less obvious introductions and start doing more major consolidation and simplification of the stdlib, those changes may be worthy of discussion to ensure the details are right.

-Chris

On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

We’re having a bit of a debate <https://github.com/apple/swift/pull/12910> over the question of whether SE-0143 “Conditional Conformances” <https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md> actually proposes any standard library changes at all, or whether they should all be brought up separately. So, I’ll pitch the pieces that I’d love to put into 4.1 to see if they’re as obvious as I think they should be

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary conform to Equatable when their type parameters are Equatable (and Set always conform to Equatable). Specifically, add to the standard library:

  extension Optional: Equatable where Wrapped: Equatable { /*== already exists */ }
  extension Array: Equatable where Element: Equatable { /*== already exists */ }
  extension ArraySlice: Equatable where Element: Equatable { /*== already exists */ }
  extension ContiguousArray: Equatable where Element: Equatable { /*== already exists */ }
  extension Dictionary: Equatable where Value: Equatable { /*== already exists */ }
  extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a highly-requested feature and an obvious “first use” of conditional conformances for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

hooman · November 22, 2017, 8:04pm

+1 Agree with Chris with Doug’s suggestion to amend SE-0143 to document it.

···

On Nov 22, 2017, at 10:08 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
On Nov 22, 2017, at 9:48 AM, Chris Lattner <clattner@nondot.org <mailto:clattner@nondot.org>> wrote:

IMO this is obvious and you should put it in.

The process serves a purpose: to ensure the evolution of the language is going in the right place, both directionally in an details. It is obvious that we’re going to take this, and the details are clear, therefore doing an evolution cycle for this would just waste everyone’s time.

I’ve been leaning this way as well. We can treat this small addition as an amendment to SE-0143 so the change is documented appropriately.

That said, when you get to less obvious introductions and start doing more major consolidation and simplification of the stdlib, those changes may be worthy of discussion to ensure the details are right.

Right. All of the consolidation of the various Slice and lazy types is big enough to warrant a proposal, for example.

  - Doug

-Chris

On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

We’re having a bit of a debate <https://github.com/apple/swift/pull/12910> over the question of whether SE-0143 “Conditional Conformances” <https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md> actually proposes any standard library changes at all, or whether they should all be brought up separately. So, I’ll pitch the pieces that I’d love to put into 4.1 to see if they’re as obvious as I think they should be

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary conform to Equatable when their type parameters are Equatable (and Set always conform to Equatable). Specifically, add to the standard library:

  extension Optional: Equatable where Wrapped: Equatable { /*== already exists */ }
  extension Array: Equatable where Element: Equatable { /*== already exists */ }
  extension ArraySlice: Equatable where Element: Equatable { /*== already exists */ }
  extension ContiguousArray: Equatable where Element: Equatable { /*== already exists */ }
  extension Dictionary: Equatable where Value: Equatable { /*== already exists */ }
  extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a highly-requested feature and an obvious “first use” of conditional conformances for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

John_McCall · November 27, 2017, 5:21am

Sent from my iPhone

IMO this is obvious and you should put it in.

The process serves a purpose: to ensure the evolution of the language is going in the right place, both directionally in an details. It is obvious that we’re going to take this, and the details are clear, therefore doing an evolution cycle for this would just waste everyone’s time.

I’ve been leaning this way as well. We can treat this small addition as an amendment to SE-0143 so the change is documented appropriately.

Agreed. I think bringing it up here and letting it "pass by acclamation" is the appropriate process; doing a separate proposal would be a waste.

John.

···

On Nov 22, 2017, at 1:08 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
On Nov 22, 2017, at 9:48 AM, Chris Lattner <clattner@nondot.org <mailto:clattner@nondot.org>> wrote:

That said, when you get to less obvious introductions and start doing more major consolidation and simplification of the stdlib, those changes may be worthy of discussion to ensure the details are right.

Right. All of the consolidation of the various Slice and lazy types is big enough to warrant a proposal, for example.

  - Doug

-Chris

On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

We’re having a bit of a debate <https://github.com/apple/swift/pull/12910> over the question of whether SE-0143 “Conditional Conformances” <https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md> actually proposes any standard library changes at all, or whether they should all be brought up separately. So, I’ll pitch the pieces that I’d love to put into 4.1 to see if they’re as obvious as I think they should be

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary conform to Equatable when their type parameters are Equatable (and Set always conform to Equatable). Specifically, add to the standard library:

  extension Optional: Equatable where Wrapped: Equatable { /*== already exists */ }
  extension Array: Equatable where Element: Equatable { /*== already exists */ }
  extension ArraySlice: Equatable where Element: Equatable { /*== already exists */ }
  extension ContiguousArray: Equatable where Element: Equatable { /*== already exists */ }
  extension Dictionary: Equatable where Value: Equatable { /*== already exists */ }
  extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a highly-requested feature and an obvious “first use” of conditional conformances for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

allevato · November 22, 2017, 8:08pm

Agree with the sentiment above. Equatable conformance for collections is
not just an obvious consequence of SE-0143 but one of the motivators—after
all, Array is mentioned right in the intro. Let it be done without a full
review cycle

···

On Wed, Nov 22, 2017 at 12:04 PM Hooman Mehr via swift-evolution < swift-evolution@swift.org> wrote:

+1 Agree with Chris with Doug’s suggestion to amend SE-0143 to document it.

On Nov 22, 2017, at 10:08 AM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote:
On Nov 22, 2017, at 9:48 AM, Chris Lattner <clattner@nondot.org> wrote:

IMO this is obvious and you should put it in.

The process serves a purpose: to ensure the evolution of the language is
going in the right place, both directionally in an details. It is obvious
that we’re going to take this, and the details are clear, therefore doing
an evolution cycle for this would just waste everyone’s time.

I’ve been leaning this way as well. We can treat this small addition as an
amendment to SE-0143 so the change is documented appropriately.

That said, when you get to less obvious introductions and start doing more
major consolidation and simplification of the stdlib, those changes may be
worthy of discussion to ensure the details are right.

Right. All of the consolidation of the various Slice and lazy types is big
enough to warrant a proposal, for example.

- Doug

-Chris

On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all,

We’re having a bit of a debate <https://github.com/apple/swift/pull/12910> over
the question of whether SE-0143 “Conditional Conformances”
<https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md> actually
proposes any standard library changes at all, or whether they should all be
brought up separately. So, I’ll pitch the pieces that I’d love to put into
4.1 to see if they’re as obvious as I think they should be

Proposal: make Optional, Array, ArraySlice, ContiguousArray, and
Dictionary conform to Equatable when their type parameters are Equatable
(and Set always conform to Equatable). Specifically, add to the standard
library:

extension Optional: Equatable where Wrapped: Equatable { /*== already
exists */ }
extension Array: Equatable where Element: Equatable { /*== already exists
*/ }
extension ArraySlice: Equatable where Element: Equatable { /*== already
exists */ }
extension ContiguousArray: Equatable where Element: Equatable { /*==
already exists */ }
extension Dictionary: Equatable where Value: Equatable { /*== already
exists */ }
extension Set: Equatable { /*== already exists */ }

Motivation: we need these for ==/!= to properly compose. It’s a
highly-requested feature and an obvious “first use” of conditional
conformances for the standard library that is unlikely to break any code.

Implementation: https://github.com/apple/swift/pull/13046

Thoughts?

- Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Douglas_Gregor · November 28, 2017, 6:05pm

To close the loop here, the core team has agreed to this as an amendment to SE-0143, and the changed has been merged here:

https://github.com/apple/swift-evolution/pull/769

and we’ve merged the change into the Swift standard library for Swift 4.1, here:

https://github.com/apple/swift/pull/13046

- Doug

···

On Nov 26, 2017, at 9:21 PM, John McCall <rjmccall@apple.com> wrote:

On Nov 22, 2017, at 1:08 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sent from my iPhone

On Nov 22, 2017, at 9:48 AM, Chris Lattner <clattner@nondot.org <mailto:clattner@nondot.org>> wrote:

IMO this is obvious and you should put it in.

The process serves a purpose: to ensure the evolution of the language is going in the right place, both directionally in an details. It is obvious that we’re going to take this, and the details are clear, therefore doing an evolution cycle for this would just waste everyone’s time.

I’ve been leaning this way as well. We can treat this small addition as an amendment to SE-0143 so the change is documented appropriately.

Agreed. I think bringing it up here and letting it "pass by acclamation" is the appropriate process; doing a separate proposal would be a waste.

Nevin · November 28, 2017, 7:37pm

Huzzah!

···

On Tue, Nov 28, 2017 at 1:05 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote:

To close the loop here, the core team has agreed to this as an amendment
to SE-0143, and the changed has been merged here:

https://github.com/apple/swift-evolution/pull/769

and we’ve merged the change into the Swift standard library for Swift 4.1,
here:

https://github.com/apple/swift/pull/13046

- Doug