Note much more then just Apple's frameworks leverage the optional protocol feature of Objective-C. It really is tied to a feature of objective-c and its dynamic runtime.
On Mon, Apr 25, 2016 at 10:30 PM Daniel Steinberg via swift-evolution < swift-evolution@swift.org> wrote: > I am very glad to see that Swift protocols will not support optional > requirements. > > I wonder, however, if @objc is the wrong label. The requirement is less > because of Objective-C and more because of Cocoa/Cocoa Touch APIs. I wonder > if it’s useful to separate which things are being implemented because of > differences between Swift and Objective-C and which things are being > implemented for compatibility with Cocoa APIs which happen to be written in > Objective-C. > > A second example might be IBOutlets which are vars and have types such as > UILabel! because of how storyboards and nibs come to life. Perhaps an > @cocoa decoration there might allow them to be let and type UILabel to > imply that they should be initialized once and before they are used - a > runtime crash at development time in the case of an unconnected outlet > would be expected. > > In any case, I am generally for the proposal but wondering if an @cocoa > tag might be more descriptive than @objc. > > Best, > > Daniel > > > > On Apr 25, 2016, at 7:13 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Apr 25, 2016, at 10:49 AM, Douglas Gregor <dgre...@apple.com> wrote: > > * 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. > > > Fair enough point but one that doesn't really sway me enough to include a > native keyword for an ObjC compatibility feature. > > * 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. > > > Sounds like we're agreed on this point. > > 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. > > > And this is something I *did* overlook. Is there leeway to add labeled > items `@objc(x: y)`? If so, `@objc(something)` could transition to > `@objc(somelabel: something)` and a separate label be used for this. > > The key point I want to make is that something that is semantically and > syntactically external to the language should enter through a well > regulated gateway. That gateway should be marked in some fashion that > contextualizes its use and understanding to the foreign source so it's > immediately understood to be non-native. It doesn't have to be part of > `@objc` but things that aren't Swift native should never have a first class > presence in the language. The approach to supporting one non-native > language should be extensible to supporting other non-native languages. > > -- E > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution