> On Apr 25, 2016, at 11:49 AM, Douglas Gregor <[email protected]> wrote: > >> >> On Apr 25, 2016, at 10:13 AM, Erica Sadun <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On Apr 25, 2016, at 10:49 AM, Douglas Gregor <[email protected] >>> <mailto:[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. > > It’s a contextual keyword, so the impact is far less than a full-fledged > keyword (but, point taken).
Ah, right. >>>> 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. > > @objc(x: y) looks suspiciously like a typo for the selector @objc(x:y:). Oh lord yes. Yes, it does. *headdesk*. >> 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. > > It’s not semantically and syntactically external. It is a real feature with > specific, unique type-checking behavior. It is externally-motivated, and > limited to interoperability with another language, but that doesn’t make it > an external feature in the way that (say) some other tool that generates > Swift code is external. I think I made my points at least in terms of objc optional requirements though: 1. I think it's a very good thing. 2. I wish there were a better way to express it. -- E, cc'ing in Chris who I believe *is* the review manager for SE-0070
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
