> On May 29, 2016, at 3:31 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > > > 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.
Considering it can all be done without deriving, so I wager they will never add it > >> >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
