> On Apr 25, 2016, at 10:49 AM, Douglas Gregor <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
