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 < [email protected]> 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 < > [email protected]> wrote: > On Nov 22, 2017, at 9:48 AM, Chris Lattner <[email protected]> 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 < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
