> On Apr 12, 2016, at 11:24 PM, Douglas Gregor <[email protected]> wrote:
>
>
>> On Apr 11, 2016, at 10:15 AM, Joe Groff <[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.
>
> 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
>> 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
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
