[swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

[Xiaodi Wu]

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 <
swift-evolution at swift.org> wrote:

>
> On Apr 24, 2016, at 3:28 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> Sent from my iPhone
>
> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu <xiaodi.wu at 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:
>
> * 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160425/b68e1c77/attachment.html>