> On Apr 25, 2016, at 10:13 AM, Erica Sadun <[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).
>
>>> 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:).
>
> 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.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
