<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="">As stated previously, I think a more specific solution is the best way to address the initialization / setup / configuration problem. While that is the case I did think some more about the ideas in this thread.<div class=""><br class=""><div class="">I believe two things are being proposed here:</div><div class=""><br class=""></div><div class="">1. The ability to append a trailing closure to any initializer (that doesn’t already declare one itself) that accepts a single argument of the initialized type. If the caller supplies such a closure, the compiler performs a code transformation as follows:</div><div class=""><br class=""></div><div class="">let questionLabel = UILabel() {<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>$0.textAlignment = .Center<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>$0.font = UIFont(name:"DnealianManuscript", size: 72)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>$0.numberOfLines = 0<br class="">}<br class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">becomes something like this (which is valid Swift today:</div><div class=""><br class=""></div><div class="">let questionLabel = UILabel(); {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>$0.textAlignment = .Center<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>$0.font = UIFont(name:"DnealianManuscript", size: 72)<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>$0.numberOfLines = 0<br class="">}(questionLabel)</div><div class=""><br class=""></div><div class=""><div dir="ltr" class=""><div class=""><div class="">The code transformation doesn’t actually buy us much. I’m a big believer in removing the need for clutter and boilerplate as much as possible, but even I must admit that the difference is really small and can be reduced a bit further using currently valid Swift code as demonstrated by the “configuration operator” mentioned in the previous post.</div></div></div></div></div></div></div><div class=""><br class=""></div><div class="">2. A new abbreviation of the $0 shorthand that would be valid only as the first characters on a line of code. For consistency this shorthand should work in any closure, not just in “setup closures”. I agree that $0 is uglier than necessary in this use case which would be relatively common in Cocoa code if this pattern becomes common.</div><div class=""><br class=""></div><div class="">The biggest drawback I can think of to a feature like this is that it is a feature specifically designed to make the use of var members more convenient. It might be a good thing that “setup closures" are a little bit ugly given that they are only able to “setup" mutable members and require those members to be initialized to potentially meaningless default values (or worse, IUO members defaulted to nil!). </div><div class=""><br class=""></div><div class="">Ideally an instance would be configured correctly when the initializer completes and we should work to find language solutions to make this safe and convenient. Once we have the right language solutions ideally we can use them in new types and retrofit existing types to use them over time, thus eliminating the need for “setup closures” alltogether.</div><div class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 5, 2015, at 6:16 PM, ilya via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">> PROBLEM: With many Apple-supplied classes, typical initializers fail to fully set up an instance for use. Here's one example: ...<div class=""><br class=""></div><div class="">FWIW, I created a configuration operator more then a year ago, and use it in all of my Swift projects:</div><div class=""><br class=""></div><div class=""><div class="">let task = NSTask() +=+ {</div><div class=""> $0.launchPath = "/usr/bin/mdfind"</div><div class=""> $0.arguments = ["kMDItemDisplayName == *.playground"]</div><div class=""> $0.standardOutput = pipe</div><div class="">}</div><div class=""><br class=""></div><div class="">Note you can also use the configured object in the rhs:</div><div class=""><br class=""></div><div class=""><div class="">let questionLabel = UILabel() +=+ {</div><div class=""> $0.textAlignment = .Center</div><div class=""> $0.font = UIFont(name:"DnealianManuscript", size: 72)</div><div class=""> $0.text = currentQuestion.questionText</div><div class=""> $0.numberOfLines = 0</div></div><div class=""> view.addSubview($0)</div><div class="">}</div><div class=""><br class=""></div></div><div class="">This $0. certainly looks ugly and it would be great to be able to simplify this. I don't llike the following much though (dot-syntax can be ambiguos here, and using simply a method name is even worse):</div><div class=""><br class=""></div><div class=""><div class="">let questionLabel = UILabel() +=+ {</div><div class=""> .textAlignment = .Center</div><div class=""> .font = UIFont(name:"DnealianManuscript", size: 72)</div><div class=""> .text = currentQuestion.questionText</div><div class=""> .numberOfLines = 0</div><div class=""> view.addSubview($0)</div><div class="">}</div></div><div class=""><br class=""></div><div class="">Actually I would be happy with something like</div><div class=""><br class=""></div><div class=""><div class="">let questionLabel = UILabel() .{</div><div class=""> ..textAlignment = .Center</div><div class=""> ..font = UIFont(name:"DnealianManuscript", size: 72)</div><div class=""> ..text = currentQuestion.questionText</div><div class=""> ..numberOfLines = 0</div><div class=""> view.addSubview($0)</div><div class="">}</div></div><div class=""><br class=""></div><div class="">Other thoughts?</div><div class=""><br class=""></div><div class=""> </div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAe8B8MzSOcPfOWknB-2BQk-2BGPePX-2BaX6I14X4zJx1Q2BNBc9fzi-2FpNDLO9OONBE3jaXwkfdK3eVBRbPWAlakQJevQl2QMZSlBrMQ4HsygNEmx6pjQyQO3-2F1Mey7I9H4rme566LnmxBtzz-2Fhxkk8olnvqW0SfWxVj0ivyEh0-2BT1CBOY-2Ff5GRtuAsWyUYcLwA-2BkU0E-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<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=""></div></div></div></body></html>