> On Apr 13, 2016, at 11:42 AM, Douglas Gregor <[email protected]> wrote: > >> >> On Apr 11, 2016, at 10:30 AM, Matthew Johnson <[email protected]> wrote: >> >> >> >> Sent from my iPad >> >>> On Apr 11, 2016, at 12:15 PM, 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. >> >> Do you have the same thought for optional closure properties? If so and >> heightForRow was an optional closure property it would satisfy all use cases >> elegantly. It could have a default implementation that returns nil. When >> non-uniform heights are required a normal method implementation can be >> provided. Delegates that have uniform row heights some of the time, but not >> all of the time, would also be supported by implementing the property. > > There are still some issues here: > > 1) It doesn’t handle optional read/write properties at all, because the > setter signature would be different. Perhaps some future lens design would > make this possible. For now, the workaround would have to be importing the > setter as a second optional closure property, I guess. (The current system is > similarly broken).
I was only thinking about methods, not properties. :) How common are optional, writeable property requirements? I don’t have a good guess off the top of my head, but my hunch is that they are not that common. If they aren’t, maybe a workaround would be acceptable (at least until a lens design comes along in the future). > > 2) For an @objc protocol, you won’t actually be able to fully implement the > optional closure property with a property of optional type, because “return > nil” in the getter is not the same as “-respondsToSelector: returns false”. > Indeed, the getter result type/setter parameter type should be non-optional, > so we would (at best) need a special rule that optional closure properties of > @objc protocols can only be implemented by non-optional properties of closure > type or by methods. This is related to why I asked about feasibility. I know that “return nil” is not that same as a “respondsToSelector:” implementation that returns false if the property was implemented to return nil. Some magic would need to handle that translation to make it work with existing Objective-C protocols. This would automate what I have done in Objective-C several times by implementing respondsToSelector manually to hide protocol method implementations when necessary. The advantage of going this route is that Swift implementations of the legacy Cocoa protocols will still function as expected in Cocoa while fitting the Swift model much better than optional protocol requirements. > >> If we decide to favor this approach it would be really nice to be able to >> import Cocoa delegate protocols this way. Is that something that might be >> feasible? > > > Yes. If we favor this approach, it should be fairly direct to make imported > Objective-C protocols work this way. > > - Doug
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
