Sent from my iPad
> On May 29, 2016, at 8:25 AM, Vladimir.S <[email protected]> wrote: > > > Should 'deriving' allows us to manually implement protocol requirements? For > example > struct A : deriving Hashable { > var hasValue : Int {...} > } > > Or there should be a compilation error in this case? This should be an error. If you want to implement it manually your should use the usual conformance declaration syntax. > > Right now I feel that if we can have auto-deriving by using current syntax > for protocol conformance - we sholdn't introduce new keyword and new rules > for this. We've already covered the reasons why this is problematic. It's better to be explicit about the request for synthesized conformance. > The requirement to explicitly conform your type to protocol for auto-deriving > is IMO reasonable compromise between separate 'deriving' decoration and > implicit derivation(when your type is Hashable without any conformance to > protocol, just if each property is Hashable). > >> On 29.05.2016 14:42, Matthew Johnson via swift-evolution wrote: >> >> >> Sent from my iPad >> >> On May 29, 2016, at 12:28 AM, Patrick Smith <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Yeah I don’t see a problem. It’s the same way that protocol extensions >>> just work. Think of this automatic synthesis as a really flexible >>> protocol extension: >>> >>> extension Hashable where Members : Hashable { >>> var hashValue : Int { >>> return self.allMembers.reduce(^) // Or whatever combiner is best >>> } >>> } >> >> Protocol extensions require you to declare conformance before your type >> receives their implementation and it must be identical for all do >> conforming types. >> >> You should have to declare conformance to receive Equatable conformance and >> synthesis. IMO it makes sense to do that with 'deriving' which makes it >> clear that you are requesting synthesized rather than manual conformance. >> >>> >>> >>>> On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> The problem with this is that it doesn’t differentiate between >>>>> synthesized and manual conformance. You won’t get error messages you >>>>> otherwise would when you intend to supply manual conformance. It is >>>>> also less clear to a reader of the code that the default, compiler >>>>> synthesized implementation is being generated. >>>> >>>> I don’t think it’s reasonable to force the language down the path where >>>> developers don’t have to be familiar with its features in order to use >>>> them correctly. If types in Swift were to automatically gain Equatable >>>> and Hashable conformances whenever they were used by something that >>>> required them, that would be a core language feature, like type >>>> inference, that even junior developers in the language would need to >>>> know. Yet few (though not none) would insist that all types be manually >>>> declared, despite otherwise not knowing when our type inference goes >>>> wrong. It’s just a basic feature of the language that anyone using the >>>> language should know about, otherwise it can bite them in the ass when >>>> weird compiler errors start popping up. >>>> Frankly, IMO, this is an obvious case of 80/20 optimization. In the vast >>>> majority of cases where my types are trivially equatable, I should just >>>> be able to declare them as such and gain the compiler-synthesized ==. In >>>> the cases where that’s not possible, the compiler can emit an error. And >>>> in the cases where I want a custom == implementation I can provide it. >>>> Requiring a new keyword and not making this feature as simple as >>>> possible because the rare developer with a custom type who doesn’t want >>>> the synthesized == they just said they did by declaring Equatable >>>> conformance is an unnecessary defaulting to the rare case. >>>> >>>> >>>> >>>> Jon Shier >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[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
