[swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

[Xiaodi Wu]

On Sun, Apr 24, 2016 at 4:28 PM, Chris Lattner <clattner at apple.com> wrote:

>
> > On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >
> > Sent from my iPhone
> >
> >> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> >>
> >> Not an expert on Obj-C compatibility in Swift by any means, but this
> >> reads like it's largely a change of nomenclature. To me, though,
> >> `objcoptional` reads exceedingly poorly. Why not emphasize the Obj-C
> >> compatibility angle by requiring the `@objc` attribute to precede each
> >> use of `optional`? (In other words, effectively rename `optional` to
> >> `@objc optional`.)
> >
> > That is a great idea.
>
> Doesn’t this have the same problem as the current (Swift 1/2)
> implementation?  People will continue to believe that it is a bug that you
> must specify @objc.
>

Perhaps they will, but IMO it's an improvement. In the current
implementation, `optional func` is spatially divorced from the `@objc`
annotation on the containing protocol. There's nothing in the code that
helps you to deduce that the two are tied to each other in some way. With
an immediate juxtaposition, it's much more explicable that optional
functions must be @objc functions. To my mind, it reads similarly to how
throwing functions must be called with some sort of `try`.

(FWIW, my hunch is that if the keyword were named `objcoptional` to begin
with, you'd still have people proposing to extend optional requirements to
pure-Swift protocols and renaming the keyword `optional`.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160424/23113ec6/attachment.html>