[swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

[Andrew Bennett]

Hi James,

I don't think it would complicate it any more than a throw normal is. You
can still use a do/catch, with types catches.

On Thursday, 28 April 2016, James Froggatt <conductator at ntlworld.com> wrote:

> Interesting idea. I tried this in a playground to see what the calling
> syntax would be like:
>
> let delegate = Optional(Delegate())
> let default = 0
> let value: Int = (try? delegate?.returnFive() ?? default) ?? default
> value
>
> Not quite as elegant at the call site, but it works. Sadly the rethrowing
> overload of ?? complicates things, I'm not sure of a way to work around
> that directly.
>
> I do like that types could potentially implement the function and do
> something, then throw an error rather than returning a value, which would
> allow them opt into using the default value. It would complicate matters if
> the conforming types throw multiple errors for whatever reason, though.
>
> From James F
>
> On 27 Apr 2016, at 15:30, Andrew Bennett <cacoyi at gmail.com
> <javascript:_e(%7B%7D,'cvml','cacoyi at gmail.com');>> wrote:
>
> Sorry if this has been discussed, but have you considered dropping
> optional entirely, making it throw, and a default implementation that
> throws a selector not found exception?
>
> This is approximately what you would expect using it in objc. I don't
> think it has the complexity discussed in the proposals alternatives for
> other call site issues.
>
> If it throws you can call with "try?" to get similar functionality in most
> cases.
>
> This assumes that respondsToSelector doesn't pick up the Swift default
> implementation.
>
> On Wednesday, 27 April 2016, James Froggatt via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
>> Thanks again.
>>
>> I had a look at the links in the proposal as you suggested, and I see a
>> lot of people pointing to protocol extensions as a solution (and
>> counter-arguments of the inability to optimise code with this method, which
>> are left unresolved).
>>
>> To make use of the protocol extensions solution, one would have to define
>> the protocol, add a protocol extension which implements every function,
>> then add an empty type which allows access to these implementations.
>> For a recommended alternative, this seems a lot of work. In a world where
>> Swift didn't have Objective C compatibility, and this empty-type workaround
>> to access defaults was the best option available, I'd be inclined to
>> support a proposal to add optional method requirements. It has the added
>> optimisation and easy delegate-swapping relative to closure properties, as
>> you mentioned, and feels less hacky than the closure-function switching
>> suggested in the proposal.
>>
>> The protocol extension + default type would provide a direct alternative,
>> but it leads me to wonder what exactly we're trying to avoid by
>> discouraging optional methods. The potential for unexpected optimisation,
>> which seems to be the primary issue, is unsolved, since the type can check
>> to see if the delegate is its own, default type, and proceed to ignore the
>> method regardless. In exchange, we make things much harder for types simply
>> wishing to have a default value when there is no registered delegate.
>>
>> So what aspect of optional protocol requirements are we actually trying
>> to discourage, which isn't present in protocol extensions?
>>
>> PS. If we're concerned about overlap with protocol extensions: it seems a
>> bit like eliminating functions from the language because they overlap with
>> the more general concept of closures. It's a fine idea, but it seems more
>> reasonable to find a solution that handles both cases conveniently before
>> we start eliminating one of them.
>>
>> From James F
>>
>> > On 26 Apr 2016, at 22:56, Douglas Gregor <dgregor at apple.com> wrote:
>> >
>> >
>> >> On Apr 26, 2016, at 3:33 AM, James Froggatt <conductator at ntlworld.com>
>> wrote:
>> >>
>> >> Fair enough. Upon reflection, I think my real issue is somewhat
>> different to what I suggested previously.
>> >>
>> >> I wasn't intending to suggest such a thing would be practical, just
>> that it would be a decent alternative to optional protocol requirements.
>> The alternative given in the proposal seems to be more of a way to remove
>> optional protocol requirements on the surface, while actually helping to
>> make them a native feature, if you see what I mean. It's not a realistic
>> alternative - it's a worse syntax for the exact same thing, which also
>> comes with awful side-effects for Swift as a whole. No-one would ever
>> seriously consider this as an alternative, yet it's listed as under the
>> heading ‘Alternatives Considered’.
>> >
>> > If you follow the swift-evolution discussion links in the proposal,
>> you’ll note that a number of people have proposed exactly what is listed in
>> “Alternatives Considered”. The only truly wacky idea in there is my
>> caller-side default implementations idea, which I covered simply because it
>> was my last stab at eliminating optional requirements before giving up and
>> sequestering them permanently behind “@objc”.
>> >
>> >>
>> >> You say the arguments given against optional closure properties are
>> strong, but I don't they would be nearly as relevant to the case I
>> suggested. By making them properties of the table view, the tableView
>> parameter would be eliminated, meaning the property names could be unique.
>> >>
>> >> EG:
>> >> var numberOfRows: (inSection: Int) -> Int
>> >> var cellForRow:: (at: NSIndexPath) -> UITableViewCell
>> >> var moveRow: (from: NSIndexPath, to: NSIndexPath)
>> >>
>> >> This removes the need to add the mentioned workarounds, since a
>> function could be assigned to the closure property just as easily as an
>> inline closure. I feel this is much more worthy of being considered as an
>> alternative. The idea of these proposals is to document why we do things,
>> so at least for someone wondering why we require all this @objc syntax
>> rather than support optional protocol requirements natively, this would
>> actually present them with a viable alternative which could be applied in
>> their APIs.
>> >
>> > Doing this implies creating a potentially large number of stored
>> closure properties, which is not as storage-efficient as storing a single
>> delegate reference. Moreover, it makes it harder to set up your
>> customization points: instead of implementing one protocol, you’re writing
>> assignments into some number of stored closure properties. Imaging trying
>> to change the delegate to some other delegate temporarily: you would have
>> to manually store each of the closures into some local structure and
>> introduce your own, except that you can’t get them all because some new
>> version of the platform would add new stored closure properties. Finally,
>> Cocoa just doesn’t work like this, so you would require some massive
>> re-architecture to get there. I don’t see how this is a better design.
>> >
>> >   - Doug
>> >
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160428/a790b13b/attachment.html>