> On Apr 24, 2016, at 7:02 PM, Erica Sadun <er...@ericasadun.com> wrote:
>
>
>> On Apr 24, 2016, at 3:28 PM, Chris Lattner via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>
>>> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>>> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu <xiaodi...@gmail.com
>>>> <mailto:xiaodi...@gmail.com>> 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:
> * Swift's "optional" protocol implementations are no such thing. They are
> default implementations that can be overridden.
(Pulling this one out first). When I read “a default implementation that can be
overridden”, I think of the conforming type *or a subclass thereof* providing a
different implementation from the default. “Optional” requirements are things
that the conforming type does not have to provide…. and a user of the protocol
must cope with conforming types that don’t provide them.
> (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.)
This is a commonly-requested feature that I don’t think we need. The TL;DR
version is that I feel like specifying the conformance explicitly (my type Foo
conforms to protocol P) already expresses intent, and the compiler should help
with the rest. I’ve recently been working on providing better warnings for
cases where one has tried to implement an optional requirement for a protocol
(but got the declaration wrong), and I think we can turn it on for cases where
one got a default implementation instead:
http://thread.gmane.org/gmane.comp.lang.swift.devel/1799
>
> * Optional requirement is an oxymoron. (This is a redux of my previous
> contribution to this topic but it's a good starting point.)
>
> * 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.
> * 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.
> 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.
- Doug
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
