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

[Shawn Erickson]

Note much more then just Apple's frameworks leverage the optional protocol
feature of Objective-C. It really is tied to a feature of objective-c and
its dynamic runtime.

On Mon, Apr 25, 2016 at 10:30 PM Daniel Steinberg via swift-evolution <
swift-evolution at swift.org> wrote:

> I am very glad to see that Swift protocols will not support optional
> requirements.
>
> I wonder, however, if @objc is the wrong label. The requirement is less
> because of Objective-C and more because of Cocoa/Cocoa Touch APIs. I wonder
> if it’s useful to separate which things are being implemented because of
> differences between Swift and Objective-C and which things are being
> implemented for compatibility with Cocoa APIs which happen to be written in
> Objective-C.
>
> A second example might be IBOutlets which are vars and have types such as
> UILabel! because of how storyboards and nibs come to life. Perhaps an
> @cocoa decoration there might allow them to be let and type UILabel to
> imply that they should be initialized once and before they are used - a
> runtime crash at development time in the case of an unconnected outlet
> would be expected.
>
> In any case, I am generally for the proposal but wondering if an @cocoa
> tag might be more descriptive than @objc.
>
> Best,
>
> Daniel
>
>
>
> On Apr 25, 2016, at 7:13 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Apr 25, 2016, at 10:49 AM, Douglas Gregor <dgregor at apple.com> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20160426/fea7906d/attachment.html>