While I agree that it would be nice to handle tuples in those contexts, it also adds a fair amount of complexity to the implementation of the synthesis. I imagine that time would be better spent just making tuples conform to Equatable/Hashable properly instead of hacking it, because then the support falls out naturally; I'd strongly prefer not to squeeze in more special cases to the proposal that could be done additively later.
Likewise, proposing a new public addition to the standard library would inspire far more design discussion than I believe we have time for if we want this to make Swift 4. :) On Tue, May 9, 2017 at 3:48 PM Andrew Bennett <[email protected]> wrote: > Also, when implementing this proposal it's going to be necessary to > combine multiple hashes together. It would be awesome if this was done in a > reusable way. If it doesn't slow the proposal down it would be awesome if > it also introduced a stdlib function: > > public func combine_hashes(_ elements: [Int]) -> Int { > > ... > > } > > Thanks! > Andrew > > On Wed, May 10, 2017 at 8:45 AM, Andrew Bennett <[email protected]> wrote: > >> You state that you will not synthesise conformance for tuples, I agree >> with this, but if a struct or enum holds a tuple it would be nice if it >> could be hashed if its members are all hashable. >> >> struct A { >> >> var a: Int, b: Int, c: Int >> >> } >> >> >> struct B { >> >> var tuple: (a: Int, b: Int, c: Int) >> >> } >> >> I'd consider these two to be equivalent as far as this proposal is >> concerned, it would be nice if the proposal made that explicit. >> >> >> On Tue, May 9, 2017 at 7:17 AM, Tony Allevato via swift-evolution < >> [email protected]> wrote: >> >>> >>> >>> On Mon, May 8, 2017 at 2:11 PM Matthew Johnson <[email protected]> >>> wrote: >>> >>>> On May 8, 2017, at 4:02 PM, Tony Allevato <[email protected]> >>>> wrote: >>>> >>>> On Sat, May 6, 2017 at 4:17 PM Chris Lattner <[email protected]> >>>> wrote: >>>> >>>>> On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution < >>>>> [email protected]> wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>> Can the opt-in conformance be declared in an extension? If so, can >>>>>> the extension be in a different module than the original declaration? If >>>>>> so, do you intend any restrictions, such as requiring all members of the >>>>>> type declared in a different module to be public? My initial thought is >>>>>> that this should be possible as long as all members are visible. >>>>>> >>>>> >>>>> Declaring the conformance in an extension in the same module should >>>>> definitely be allowed; >>>>> >>>>> >>>>> Please follow the precedent of the Codable proposal as closely as >>>>> possible. If you’d like this to be successful for Swift 4, you should >>>>> look >>>>> to scope it as narrowly as possible. Because it is additive (with >>>>> opt-in), >>>>> it can always be extended in the future. >>>>> >>>>> I believe this would currently be the only way to support conditional >>>>> conformances (such as the `Optional: Hashable where Wrapped: Hashable` >>>>> example in the updated draft), without requiring deeper syntactic changes. >>>>> >>>>> >>>>> This proposal doesn’t need to cover all cases, since it is just >>>>> sugaring a (very common) situation. Conditional conformances to Hashable >>>>> could be written manually. >>>>> >>>>> I'm less sure about conformances being added in other modules, >>>>> >>>>> >>>>> It is a bad idea, it would break resilience of the extended type. >>>>> >>>>> But after writing this all out, I'm inclined to agree that I'd rather >>>>> see structs/enums make it into Swift 4 even if it meant pushing classes to >>>>> Swift 4+x. >>>>> >>>>> >>>>> Agreed, keep it narrow to start with. >>>>> >>>>> Also, I don’t know how the rest of the core team feels about this, but >>>>> I suspect that they will be reticent to take an additive proposal at this >>>>> late point in the schedule, unless someone is willing to step up to >>>>> provide >>>>> an implementation. >>>>> >>>> >>>> That someone is me :) I have a branch where it's working for enums >>>> (modulo some weirdness I need to fix after rebasing a two-month-old state), >>>> and adapting that logic to structs should hopefully be straightforward >>>> after that. Going with the more narrowly-scoped proposal and making >>>> conformances explicit simplifies the implementation a great deal as well (I >>>> was previously blocked with recursive types when it was implicit). >>>> >>>> Thanks for the feedback—after consideration, I've pulled classes out of >>>> the proposal completely (even non-final) and mentioned the other >>>> limitations so we'd have a record of what was discussed in this thread. >>>> >>>> I've created a PR for the proposal text, in the event that the core >>>> team is interested in moving this forward: >>>> https://github.com/apple/swift-evolution/pull/706 >>>> >>>> >>>> Thanks for continuing to push this forward Tony! The current proposal >>>> looks like the right approach for getting this into Swift 4. >>>> >>>> I only have one question which I will present with an example: >>>> >>>> protocol Foo: Equatable {} >>>> protocol Bar: Hashable {} >>>> >>>> struct FooType: Foo {} >>>> struct BarType: Bar {} >>>> >>>> Do FooType and BarType receive synthesis? >>>> >>> >>> Great question! Yes they should. It's "explicit" transitively since the >>> answer to "does FooType/BarType conform to Equatable/Hashable?" is still >>> "yes". (And I've confirmed that my prototype handles this case.) >>> >>> This is especially helpful since Hashable extends Equatable, so a user >>> only needs to list conformance to the former to get correctly synthesized >>> implementations of both, which helps to guarantee that they're implemented >>> consistently with respect to each other. >>> >>> >>> >>>> >>>> >>>> >>>> >>>>> >>>>> -Chris >>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> 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
