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

[Andrew Bennett]

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> 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
> <javascript:;>> wrote:
> >
> >
> >> On Apr 26, 2016, at 3:33 AM, James Froggatt <conductator at ntlworld.com
> <javascript:;>> 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 <javascript:;>
> 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/0816d259/attachment.html>