<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="">Thank you Erica,<div class=""><br class=""></div><div class="">Chris recently noted that UIColor.blackColor() will become UIColor.black() and dismissViewControllerAnimated(true, completion: nil) will become dismissAnimated(true, completion: nil).</div><div class=""><br class=""></div><div class="">This latter prompted me to wonder - as the first parameter’s name is flag and first labels will be exposed shouldn’t this be</div><div class=""><br class=""></div><div class="">dismiss(animated: true, completion: nil)</div><div class=""><br class=""></div><div class="">This, in turn led me to ask - don’t we most often want the first parameter to be true and the second to be nil? It is only an exceptional case where we don’t. Why don’t we take advantage of Swift’s default parameters to let this be</div><div class=""><br class=""></div><div class="">dismiss()</div><div class=""><br class=""></div><div class="">Similarly, UIButtons in UIKit stand out from UILabel’s and other widgets when we get and set titles/text. In the pair title(forState:), set(title:, forState:), we we took advantage of the default value .Normal for state then we’d have calls like this</div><div class=""><br class=""></div><div class="">button.title()</div><div class="">button.setTitle(“Hello”)</div><div class=""><br class=""></div><div class="">and only call out the state in cases where we were setting the title for a non-Normal state.</div><div class=""><br class=""></div><div class="">Erica raises the general question that results: there are many defaults like this that would make Swift code read more naturally when working with non-exceptional cases and would call out when we are working with exceptional cases.</div><div class=""><br class=""></div><div class=""> Is there a proper way in which to request such an audit/changes? I understand that that may be a Foundation/Cocoa Evolution issue and not a Swift evolution issue.</div><div class=""><br class=""></div><div class="">It does break code - but so does changing dismissViewControllerAnimated to dismissAnimated - it seems that paying the price once would be desirable.</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">Daniel</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 8, 2016, at 1:40 PM, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Is there a best way to request default values for common Cocoa and Cocoa Touch APIs? <div class="">Now that we're moving to Swift, the language supports defaults and omitted parameters</div><div class="">but the ObjC APIs do not (yet) supply them. </div><div class=""><br class=""><div class="">For example, <font face="Menlo" class="">dismissViewControllerAnimated(flag: true, completion: nil)</font><span style="font-family: Palatino-Roman;" class=""> </span></div><div class=""><span style="font-family: Palatino-Roman;" class="">could become </span><font face="Menlo" class="">dismissAnimated()</font><span style="font-family: Palatino-Roman;" class=""> when default values are available for </span><font face="Menlo" class="">flag</font><span style="font-family: Palatino-Roman;" class=""> and </span><font face="Menlo" class="">completion</font><span style="font-family: Palatino-Roman;" class="">.</span></div><div class=""><span style="font-family: Palatino-Roman;" class="">There's a large-ish class of these boilerplate defaults and it would be nice if there were a way to</span></div><div class=""><span style="font-family: Palatino-Roman;" class="">be able to request them.</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div class=""><span style="font-family: Palatino-Roman;" class="">cc'ing in Daniel S whose idea this is.</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div class=""><span style="font-family: Palatino-Roman;" class="">Thanks, -- E</span></div></div></div></div></blockquote></div><br class=""></div></body></html>