I think there are some good points here. As a riff, though, I'd argue that Obj-C optional should *not* be renamed to elective or something else. Renaming, so far, has been for the purpose of providing first-class Swifty idioms for existing things. It makes moving between Swift-native code and legacy code more seamless and encourages increased use of what's being renamed. However, here we have something that we all agree isn't and cannot be a Swift idiom. Yes, it's true that the name clashes with Swift optional, but the very thing itself also clashes with how protocols requirements are intended to work in Swift. It *shouldn't* look like a first-class Swift concept.
On Sun, Apr 24, 2016 at 9:07 PM Erica Sadun via swift-evolution < [email protected]> wrote: > > On Apr 24, 2016, at 3:28 PM, Chris Lattner via swift-evolution < > [email protected]> wrote: > > > On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution < > [email protected]> wrote: > > > > Sent from my iPhone > > On Apr 22, 2016, at 5:56 PM, Xiaodi Wu <[email protected]> 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. > > -Chris > > > 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: > > * Optional requirement is an oxymoron. (This is a redux of my previous > contribution to this topic but it's a good starting point.) > > * Swift's "optional" protocol implementations are no such thing. They are > default implementations that can be overridden. (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.) > > * 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"? > > * 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. > 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. > > -- Erica > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
