<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Seems like an easy win, so I’m leaning towards a +1.</div><div class=""><br class=""></div><div class="">OTOH, are there any other cases where Swift -&gt; ObjC automatically changes names of things to optimize for ObjC? If we don’t do more of that (the '<font face="Helvetica Neue" class="">"Add needless words" to Objective-C method names’&nbsp;thread, or other quick wins like this one), it would be weird to make just this one exception, a single special case. I fear this would be more surprising than not changing anything at all.</font></div><br class=""><div class="">
<div class="">— Radek</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 23 Feb 2016, at 22:00, Douglas Gregor via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">The Swift API guidelines state that Boolean properties should reflect assertions about the receiver, so in Swift one would expect:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>class Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; var isEnabled: Bool // good</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div class=""><br class=""></div><div class="">rather than</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>class Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; var enabled: Bool // not Swifty</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div class=""><br class=""></div><div class="">When the property is @objc, e.g.,</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>class Foo : NSObject {</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; @objc var isEnabled: Bool</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div class=""><br class=""></div><div class="">The resulting Objective-C property doesn’t follow the&nbsp;<a href="https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingIvarsAndTypes.html#//apple_ref/doc/uid/20001284-BAJGIIJE" class="">Cocoa guidelines for Objective-C</a>:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>@property (readwrite,nonatomic) BOOL isEnabled;</div><div class=""><br class=""></div><div class="">because those guidelines state that properties do not use the “is” prefix.</div><div class=""><br class=""></div><div class="">My proposal is to strip the “is” prefix from the Objective-C name, but leave it off the getter, e.g.,</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>@property (readwrite,nonatomic,getter=isEnabled) BOOL enabled;</div><div class=""><br class=""></div><div class="">The change would have no effect on the Swift name; it will only affect the Objective-C property name and setter name.</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>- Doug</div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>