> On Aug 2, 2017, at 5:30 PM, Xiaodi Wu <[email protected]> wrote: > > Besides the comments below on consensus about how to deal with the > documentation aspect, I should point out that your example is incorrect. != > is not a protocol requirement of Equatable with a default implementation, but > a protocol extension method that cannot be overridden which is *not* a > protocol requirement. That is by design. > > Additionally, it is unclear to me why default implementations should need be > provided in the same file, as your solution requires. There are good reasons > why library A that builds upon library B might supply a default > implementation in an extension for a protocol B.P that refines B.Q. To the > end user, it is just as much of a default that doesn’t need to be implemented > when conforming to P, but your proposed solution does nothing to address this > issue. >
Yes, it is restrictive. My approach to open-ended proposals like this (ones that might have unforeseen consequences) is to start with the bare minimum and work outwards from there. If the default implementation is in the same file, then the meta-information about the protocol requirement can be safely cached after compiling an individual file and it would remain valid when linking against the rest of object files in the module. I may, however, be completely wrong in how this works, so that's why I encourage people to put the proposed limitations to question. By the way, thank you for doing that 🙂 > > On Wed, Aug 2, 2017 at 03:54 Gor Gyolchanyan via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > Good day, swift community! > This time, I'd like to bring your attention to an everyday problem which, I'm > sure, you've all dealt with at some point. > > Motivation > > Many protocols have a lot of default-implemented requirements so that they > can be customized, which would otherwise be impossible to do. > For example, the Comparable protocol, which (considering its inheritance of > Equatable) states a requirement of ==, !=, <, <=, >, and >=, only requires > implementation of == and <, because all others have default implementations > in terms of these two. This forces the user to either memorize the exact set > of mandatory requirements or, in case of more complicated protocols like > Collection, constantly look up the documentation and hope that it has a > section outlining how to conform to it. > Conversely, the author of the protocol needs to manually keep track of the > requirements and their default implementations to ensure that the ones that > have to be mandatory stay mandatory and the rest of the requirements stay > default-implemented, which is also a tedious and error-prone work. > > Proposed Solution > > I'd like to propose the ability to mark select protocol requirements as > default, which would cause the following effects: > The compiler will emit a compile-time error if a default implementation is > not available in a non-constrained protocol extension in the same file and > provide a fix-it for inserting a template. > If a conforming type does not implement all requirements of the protocol, the > compiler will not produce fix-its for inserting a template for any default > requirements. > > Example > > // Equatable.swift > > protocol Equatable { > > static func == (_ some: Self, _ other: Self) -> Bool > > default static func != (_ some: Self, _ other: Self) -> Bool > ^ error: missing implementation of a default requirement `!=`; fix-it: > insert a default implementation > > } > > extension Equatable { > > static func != (_ some: Self, _ other: Self) -> Bool { > [Your Code Here] > } > > } > > // Something.swift > > struct Something: Equatable { > ^ error: missing implementation of a non-default requirement `==`; fix-it: > insert an implementation > > } > > extension Something { > > static func == (_ some: Something, _ other: Something) -> Bool { > [Your Code Here] > } > > } > > Cheers, > Gor Gyolchanyan. > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
