[swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

[Tony Allevato]

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 at 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 at swift.org> wrote:
> On Nov 22, 2017, at 9:48 AM, Chris Lattner <clattner at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20171122/0875a18b/attachment.html>