<div style="white-space:pre-wrap">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.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 25, 2016 at 10:30 PM Daniel Steinberg via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I am very glad to see that Swift protocols will not support optional requirements.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>In any case, I am generally for the proposal but wondering if an @cocoa tag might be more descriptive than @objc.</div><div><br></div><div>Best,</div><div><br></div><div>Daniel</div></div><div style="word-wrap:break-word"><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On Apr 25, 2016, at 7:13 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Apr 25, 2016, at 10:49 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>> wrote:</div><div><div style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div style="word-wrap:break-word"><div>* 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 "<i>discretionary</i>" or "<i>elective</i>" implementations. Swift has renamed lots of Objective C things (waves hi to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md" target="_blank">SE-0005</a>). Why not "optional”?</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Also, there is a link between the Optional type and optional requirements: when you reference an optional requirement, you get back an Optional.</div></div></div></blockquote><div><br></div><div>Fair enough point but one that doesn't really sway me enough to include a native keyword for an ObjC compatibility feature.</div><br><blockquote type="cite"><div style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div><div style="word-wrap:break-word"><div>* 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.<span> </span></div></div></div></blockquote><div><br></div><div>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.</div></div></blockquote><div><br></div>Sounds like we're agreed on this point.</div><div><br><blockquote type="cite"><div style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div><div style="word-wrap:break-word"><div>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.</div></div></div></blockquote><br></div><div style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Do remember that @objc(something) already has a meaning: it gives the Objective-C name “something” to the entity that the @objc(something) describes.</div></blockquote><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-- E</div><div><br></div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>