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.
I haven’t seen these come up in any discussion that wasn’t about mapping Objective-C optional requirements to something else in Swift. What other use cases are you envisioning?
The desire for labeled closure variables has come up a few times. For instance, it would provide a way to give local label names to closure arguments. In C, you can say:
void doStuff(void (*onCompletion)(void *result, void *error)) {
if (auto x = /*doStuff*/) {
onCompletion(/*result*/ x, /*error*/ nullptr);
} else {
onCompletion(/*result*/ nullptr, /*error*/ getLastError());
}
onCompletion(/*result*/ x, /*error*/ y);
}
where `result` and `error` don't affect the type, but describe the use of the parameters to the completion closure. It'd be nice to do the same in Swift:
func doStuff(onCompletion completed(result:error:): (AnyObject?, AnyObject?) -> ()) {
/*doStuff*/
completed(result: x, error: nil)
}
There's also the case of using if let to test for presence of a method, where you'd really like to keep the labels on the local binding:
if let doStuff(to:with:) = object.doStuff(to:with:) {
...
}
We currently lean on the vestige of labeled-tuples-as-function-arguments to do this, but I think we ultimately want to get away from that.
-Joe
···
On Apr 12, 2016, at 11:24 PM, Douglas Gregor <dgregor@apple.com> wrote:
On Apr 11, 2016, at 10:15 AM, Joe Groff <jgroff@apple.com> wrote:
On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
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,
Most of the requests I see for this feature are of the form “this works for @objc protocols, so it should work everywhere,” and most of the push-back I’ve seen against removing ‘optional’ is a concern over interaction with Cocoa. I haven’t gotten the sense that optional requirements are considered to be the best design for any particular task in Swift.
and your proposed solution makes this incredibly obscure and magical.
That’s fair. The mechanism I’m talking about *is* a bit hard to explain—we would need to rely on the diagnostic for cases where one tries to call a method that is caller-defaulted from Swift code, e.g.,
error: method ‘foo(bar:wibble:)’ may not be implemented by the adopting class; add a default implementation via an extension to protocol ‘Foo'
This would only affect optional requirements of protocols imported from Objective-C. My hypothesis is that those just aren’t used in Swift app code.
- Doug