[swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only
dgregor at apple.com
Mon Apr 25 11:49:46 CDT 2016
> On Apr 24, 2016, at 7:02 PM, Erica Sadun <erica at ericasadun.com> wrote:
>> On Apr 24, 2016, at 3:28 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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.
> I thought I'd throw a few ideas into the mix. I'm arriving late to the discussion. (I didn't expect the conversation to last this long.) I did take a quick look back through the thread but I may have missed some bits along the way. Apologies in advance for any redundancy:
> * Swift's "optional" protocol implementations are no such thing. They are default implementations that can be overridden.
(Pulling this one out first). When I read “a default implementation that can be overridden”, I think of the conforming type *or a subclass thereof* providing a different implementation from the default. “Optional” requirements are things that the conforming type does not have to provide…. and a user of the protocol must cope with conforming types that don’t provide them.
> (Tangentially, why not introduce a required "override" keyword for conforming types that implement a version of a member introduced in protocol extensions? This would match the class approach and enhance safety and intent.)
This is a commonly-requested feature that I don’t think we need. The TL;DR version is that I feel like specifying the conformance explicitly (my type Foo conforms to protocol P) already expresses intent, and the compiler should help with the rest. I’ve recently been working on providing better warnings for cases where one has tried to implement an optional requirement for a protocol (but got the declaration wrong), and I think we can turn it on for cases where one got a default implementation instead:
> * Optional requirement is an oxymoron. (This is a redux of my previous contribution to this topic but it's a good starting point.)
> * Swift already has an `Optional` type. Importing ObjC "optional" protocol requirements is therefore semantically problematic from a Swift development POV. I don't like either the "@objcoptional" or "@objc optional" solutions mentioned upthread. They overload "optional" syntactically and confuse semantics. I think the key words that better describe what's happening in, for example, a `UITableViewDelegate`, are "discretionary" or "elective" implementations. Swift has renamed lots of Objective C things (waves hi to SE-0005 <https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md>). Why not "optional”?
If we were adding optional requirements to Swift protocols, I would agree that it makes sense to change the nomenclature to avoid the oxymoron and the confusion with optionals. However, since this is now moving into the realm of “Objective-C compatibility feature”, I think it’s reasonable to retain the existing, Objective-C terminology.
Also, there is a link between the Optional type and optional requirements: when you reference an optional requirement, you get back an Optional.
> * I do *support* retaining `@objc` in some form and I believe it can be addressed in a way that does not appear to be a bug. "Optional protocol conformance" is a behavior that is external to the language. I do not believe would be voluntarily added to Swift should the topic arise.
It’s a feature that exists to support compatibility with another language; we would not add it if it not for Objective-C. However, it is a real language feature with different semantics from other language features.
> Therefore I find it insufficient to introduce attributes like `@elective` or `@discretionary` in order to satisfy non-native requirements. I would prefer to see the @objc attribute be extended to support these and any future Objective-C-specific behaviors: @objc(elective), @objc(importedProtocolSupport: elective), or whatever. While these are wordy, I assume like any other Swift attributes they can be placed on a line before the function declaration, and it would be instantly clear why they've been placed there, and they would not overlap with Swift semantics *or* expectations. I leave the color of the bikeshed as an exercise for the reader.
Do remember that @objc(something) already has a meaning: it gives the Objective-C name “something” to the entity that the @objc(something) describes.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution