It would have to be compiler magic. If I recall, the only factor preventing it is that no one has implemented it, but one of the core team members has noted that it should be fairly straightforward. I don't have the time right now or I'd seriously take a stab at it.
On Fri, May 5, 2017 at 14:20 Tony Allevato <tony.allev...@gmail.com> wrote: > On Fri, May 5, 2017 at 12:18 PM Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> Hmm, with these complications, I regret suggesting that this could be >> extended to classes so easily. Definitely some interesting solutions, but >> my inclination as well would be to leave classes out entirely for the >> moment and let it percolate for Swift 4.1+. After all, it's an additive >> convenience. >> >> Any thought as to including tuples though? >> > > Can non-nominal types conform to protocols? I thought that was the main > limitation for supporting these conformances on tuples. > > I would love to support them if possible to get rid of the arbitrary == > implementations in the standard library and make multi-component dictionary > keys easier to work with, but my understanding was that the above issue was > the bigger factor preventing it. > > > > >> On Fri, May 5, 2017 at 13:51 Matthew Johnson via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> On May 5, 2017, at 1:33 PM, Tony Allevato <tony.allev...@gmail.com> >>> wrote: >>> >>> >>> >>> On Fri, May 5, 2017 at 11:07 AM Matthew Johnson <matt...@anandabits.com> >>> wrote: >>> >>>> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution < >>>> swift-evolution@swift.org> wrote: >>>> >>>> Thanks for your feedback, everybody! >>>> >>>> >>>> Thanks for continuing to drive this forward! >>>> >>>> >>>> I've updated the gist >>>> <https://gist.github.com/allevato/2fd10290bfa84accfbe977d8ac07daad> to >>>> reflect what seems to be a consensus here: >>>> >>>> * Derived conformances are now opt-in (this makes the recursive case >>>> *much* cleaner, and the complexity involved in that section has been >>>> completely removed) >>>> >>>> >>>> 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; 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. >>> >>> I'm less sure about conformances being added in other modules, but I'm >>> inclined to agree with your assessment. I could see two ways of >>> interpreting it: >>> >>> * E/H can only be derived in an extension in an external module if all >>> the members are accessible (and the other conditions are met). >>> * E/H can be derived in an extension in an external module using only >>> the subset of accessible members (if the other conditions are met). >>> >>> These are subtly different. The argument for the first would be "if you >>> want to add E/H to a type in a different module, you must *consciously* >>> decide which members you want to use in those computations". The argument >>> for the second would be "you can already make a type in a different module >>> conform to E/H and you'd be restricted to the accessible members there, so >>> let's make that path easier for users too." >>> >>> The first case is probably the safer choice. I'm not sure about the >>> implementation difficulty of each. >>> >>> >>>> * Classes are supported now as well >>>> >>>> Please take a look at the updated version and let me know if there are >>>> any concerns! If folks like it, I'll prepare a pull request. >>>> >>>> >>>> Will the synthesis for classes dispatch through a non-final method >>>> which is expected to be overridden by subclasses? You don’t explicitly >>>> state this but it seems implied. If so, what if the subclass requires a >>>> custom implementation? This would require the signature of the non-final >>>> method to be part of the synthesis contract. >>>> >>> >>>> Supporting non-final classes introduces enough complexity (especially >>>> when multiple modules are involved). I would hate to see it get >>>> sidetracked in discussions regarding non-final classes and miss the Swift 4 >>>> window because of that. Given the limited time left for Swift 4 it might >>>> be better to keep the initial proposal simpler and consider a followup in >>>> the Swift 5 timeframe to build on the initial proposal. >>>> >>> >>> For ==, the operator must already be "class final" or "static" >>> regardless of this proposal, and it can't be "overridden" as such in >>> subclasses because the arguments would be different (lhs and rhs would be >>> the subclass, not the superclass). So the compiler should be able to >>> generate the correct implementation for subclasses in all cases, right? >>> >>> >>> This won’t work because Equatable has a `Self` requirement so the `==` >>> defined by the initial conforming class would be called. In order to >>> support non-final classes you would need to have that dispatch through >>> something like an `isEqual` method which *can* be overridden. >>> >>> >>> For hashValue, I think the possibilities are: >>> >>> * Sub is a subclass of Super. Super conforms to Hashable and implements >>> non-final hashValue. The compiler can derive it for Sub and call >>> super.hashValue in its implementation. >>> >>> >>> Yes, this makes sense. The primary difficulty with Hashable is that it >>> refines Equatable. Refining a non-final implementation of `hashValue` is >>> relatively straightforward. >>> >>> * Sub is a subclass of Super. Super conforms to Hashable and implements >>> a final hashValue. The compiler cannot derive one for Super and would >>> silently not do so. >>> >>> >>> Do you mean “the compiler cannot derive one for Sub”? >>> >>> * Sub is a subclass of Super. Super does not conform to Hashable, but >>> Sub asks to derive it. This can either (1) not be allowed, telling the user >>> that they need to write it manually in this case, or (2) be allowed and use >>> all accessible members to compute the hashValue (including those from the >>> superclass). >>> >>> What do Encodable/Decodable do in these situations? It seems similar >>> solutions there would apply here. >>> >>> >>> That’s a good question. I don’t recall whether this was addressed >>> explicitly or not. >>> >>> >>> 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. >>> >>> >>> That is reasonable. >>> >>> On the other hand, I think you could come up with straightforward >>> semantics for synthesizing conformance for final classes as well. Final >>> classes with no superclass should be straightforward. Final classes that >>> do have a superclass would be similarly straightforward if we decide to >>> allow this as described in option (2) above regarding hashValue. >>> >>> I’m on the fence on this - if we can include final classes using option >>> (2) without jeopardizing getting this in for Swift 4 I would support that. >>> If it’s going to put support for value types in Swift 4 at risk then I >>> would not. >>> >>> >>> >>> >>>> >>>> >>>> >>>> On Fri, May 5, 2017 at 8:16 AM Nevin Brackett-Rozinsky via >>>> swift-evolution <swift-evolution@swift.org> wrote: >>>> >>>>> On Fri, May 5, 2017 at 1:47 AM, Xiaodi Wu via swift-evolution < >>>>> swift-evolution@swift.org> wrote: >>>>> >>>>>> On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon < >>>>>> br...@architechies.com> wrote: >>>>>> >>>>>>> I would think only final classes could participate in this, since a >>>>>>> subclassable class would need to allow subclasses to override equality, >>>>>>> and >>>>>>> you can't override a static `==` operator method. >>>>>>> >>>>>> >>>>>> I work so rarely with classes that I'm embarrassed to have to ask >>>>>> this question: can classes not satisfy Equatable with a `public class >>>>>> func >>>>>> ==`? >>>>>> >>>>> >>>>> Currently: >>>>> >>>>> class C: Equatable { >>>>> class func == (lhs: C, rhs: C) -> Bool { >>>>> return lhs === rhs >>>>> } >>>>> } >>>>> >>>>> Yields an error, “Operator '==' declared in non-final class 'C' must >>>>> be 'final'”. >>>>> >>>>> Nevin >>>>> _______________________________________________ >>>>> 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 >>> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
