[swift-evolution] Will Swift ever support optional methods without @objc?

[Dave Abrahams]

on Tue Nov 15 2016, Shawn Erickson <swift-evolution at swift.org> wrote:

> This has been discussed somewhat heavily in the past and nothing yet has
> really moved forward on it. I do think a good way of doing something like
> this would be helpful. I have resulted to defining an interface with an
> extension that provides empty defaults and for each function a match bool
> var exists to imply if it exists or not. The code accepting a delegate can
> probe these bool vars to configure itself to efficiently operate based on
> knowledge about what the delegate expects (some missing from most proposed
> solutions other then @objc optional).

If there are truly programming problems that don't have a clean solution
without introducing optional requirements, I'd really like to see them.

Speaking for myself: I think “probe-a-type” programming is in general a
bad idea, and I'm opposed to adding features that encourage it.  It's
almost always better to design entry points into supertypes (protocols,
or base classes if you must ;->) with default implementations that can
be overridden to do the work you need based on the characteristics of a
subtype, rather than trying to make decisions in the caller based on the
shape of the type.  When you *do* need probing, it's a good idea to make
the set of possible subtypes a closed set, so the compiler can ensure
you handle all cases—i.e., use an enum.

> On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> One major example is the NS/UITableViewDataSource or Delegate - there are
>> many many methods that you don't need to implement, hence are optional.
>>
>> But I think that this was partially solved by default implementation of
>> protocol methods, which pretty much does what you want...
>>
>>
>> I just realized I only responded to someone else, and not the whole list.
>> It does, but it forces me to make the return value of the protocol method
>> optional, so that the default implementation can return nil.
>>
>> In the end, I guess that's not so bad, since I'm not happy with the entire
>> approach, but it'll do for now.
>>
>>
>> What's different about having the method return nil vs being optional?
>> You're attempting to call it either way, and presumably need some means of
>> handling the return value, except in Swift it's all nice and explicit and
>> easy to put in a conditional like:
>>
>> if let result = myObject.someOptionalMethod() { /* Do some stuff */ }
>> print(myObject.someOptionalStringMethod() ?? "")
>>
>> And so-on. If you need a method to be both optional, and return a nilable
>> result then you can use a double optional like so:
>>
>> if let result = myObject.someDoubleOptionalMethod() { // Method was
>> implemented
>> if let value = result { // Method returned a value
>> /* Do some stuff */
>> }
>> }
>>
>>
>> By defining the methods as returning an Optional and throwing in default
>> implementations you can specify fewer, bigger protocols and make clear what
>> the requirements really are, though personally given the choice I'd prefer
>> a dozen smaller protocols that are absolutely explicit in what they do.
>>
>> But yeah, I think the tools you need are all there already; maybe there's
>> an argument to be made for allowing default return values on protocol
>> methods, to reduce the boiler-plate?
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> I think there is a difference between:
>>
>> - A method which returns an optional result, and
>> - An optional method which, if present, always returns a result
>>
>> Perhaps not so much of a difference at the usage site (it’s just a
>> question of placing a ? for optional chaining), but semantically and when
>> conforming to the protocol, they mean different things.
>>
>> - Karl
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave