I think we have the following asks: - support methods on a protocol that may or may not be implemented by a confirming type - support statically (per type) detection of whether one of these methods have been implemented so that you can have consistent behavior while interacting with a particular type - static methods may or may not be attractive to implement via additional subtype protocol conformance (depending on how many independent optional methods exist) - support dynamically (based on internal logic and state) support a particular method, for instance with UI event dispatching - Ability to determine if a method is available on a type outside of calling it to detect default functionality - compatibility (where appropriate) with existing objc protocols with optional methods
Obviously, optional as it exists today only solves some of these asks. Some of these may not deserve to be (or be suitably improved upon by being) language features. Some of these are possible today in a form through Objective C interop, but this are not available on other platforms -DW Sent with my Thumbs > On Apr 11, 2016, at 11:15 AM, Joe Groff via swift-evolution > <[email protected]> wrote: > > >> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution >> <[email protected]> wrote: >> >> One could perhaps work around (a), (b), and (d) by allowing compound >> (function-like) names like tableView(_:viewFor:row:) for properties, and >> work around (c) by allowing a method to satisfy the requirement for a >> read-only property, but at this point you’ve invented more language hacks >> than the existing @objc-only optional requirements. So, I don’t think there >> is a solution here. > > To me, compound names for closure properties and satisfying property > requirements with methods aren't hacks, they're missing features we ought to > support anyway. I strongly prefer implementing those over your proposed > solution. It sounds to me like a lot of people using optional protocol > requirements *want* the locality of control flow visible in the caller, for > optimization or other purposes, and your proposed solution makes this > incredibly obscure and magical. > > -Joe > _______________________________________________ > 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
