> On Sep 8, 2017, at 12:46 AM, Haravikk via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On 7 Sep 2017, at 22:02, Itai Ferber <ifer...@apple.com >> <mailto:ifer...@apple.com>> wrote: >> >> protocol Fooable : Equatable { // Equatable is just a simple example >> var myFoo: Int { get } >> } >> >> extension Fooable { >> static func ==(_ lhs: Self, _ rhs: Self) -> Bool { >> return lhs.myFoo == rhs.myFoo >> } >> } >> >> struct X : Fooable { >> let myFoo: Int >> let myName: String >> // Whoops, forgot to give an implementation of == >> } >> >> print(X(myFoo: 42, myName: "Alice") == X(myFoo: 42, myName: "Bob")) // true >> This property is necessary, but not sufficient to provide a correct >> implementation. A default implementation might be able to assume something >> about the types that it defines, but it does not necessarily know enough. > > Sorry but that's a bit of a contrived example; in this case the protocol > should not implement the equality operator if more information may be > required to define equality. It should only be implemented if the protocol is > absolutely clear that .myFoo is the only part of a Fooable that can or should > be compared as equatable, e.g- if a Fooable is a database record and .myFoo > is a primary key, the data could differ but it would still be a reference to > the same record. > > To be clear, I'm not arguing that someone can't create a regular default > implementation that also makes flawed assumptions, but that > synthesised/reflective implementations by their very nature have to, as they > cannot under every circumstance guarantee correctness when using parts of a > concrete type that they know nothing about. You can’t argue this both ways: If you’re arguing this on principle, that in order for synthesized implementations to be correct, they must be able to — under every circumstance — guarantee correctness, then you have to apply the same reasoning to default protocol implementations. Given a default protocol implementation, it is possible to come up with a (no matter how contrived) case where the default implementation is wrong. Since you’re arguing this on principle, you cannot reject contrived examples. If you are arguing this in practice, then you’re going to have to back up your argument with evidence that synthesized examples are more often wrong than default implementations. You can’t declare that synthesized implementations are by nature incorrect but allow default implementations to slide because in practice, many implementations are allowable. There’s a reason why synthesis passed code review and was accepted: in the majority of cases, synthesis was deemed to be beneficial, and would provide correct behavior. If you are willing to say that yes, sometimes default implementations are wrong but overall they’re correct, you’re going to have to provide hard evidence to back up the opposite case for synthesized implementations. You stated in a previous email that "A synthesised/reflective implementation however may return a result that is simply incorrect, because it is based on assumptions made by the protocol developer, with no input from the developer of the concrete type. In this case the developer must override it in to provide correct behaviour." — if you can back this up with evidence (say, taking a survey of a large number of model types and see if in the majority of cases synthesized implementation would be incorrect) to provide a compelling argument, then this is something that we should in that case reconsider.
>>> Reflective/synthesised default implementations must by their very nature >>> make assumptions about a concrete type that are not cannot be guaranteed to >>> be correct. The properties and methods they may end up interacting withmay >>> have nothing at all to do with the protocol. Equatable remains by far the >>> simplest example; just because a developer has used equatable properties >>> does not guarantee that all of them should be compared during a check for >>> equality. >> In the same way that you might consider synthesized conformances to >> overreach into a type and touch things which are not related to a protocol, >> default implementations can be considered underreach in that they don’t know >> anything about properties which are necessary for providing a correct >> implementation. > > If more information is necessary to provide a correct implementation, then a > default implementation shouldn't be provided. This is what unimplemented > properties and methods are for; either getting the developer to provide the > missing information, or getting them to implement the correct behaviour. I agree, but you can’t selectively argue this. > _______________________________________________ > 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
