<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 21, 2016, at 9:20 PM, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline">I’m not sold on the notion of partial initializers in the first place, but if we were to go down this path, the approach of nailing down the exact initialization behavior and requirements of the partial initializer - and making it part of its explicitly declared interface - is the right way to go.</div></blockquote><div class=""><br class=""></div>Fair enough. I’m also worried about the prospect of adding even more complexity — and syntax — to Swift’s initializer model. My hope is that we can map this to existing language features somehow, or combine this with some other simplification of the initializer model so that the net complexity gain is not too high. But since I don’t have any concrete suggestions at this point, I’ll stay quiet for a while ;-)</div></div></blockquote><br class=""></div><div>Macro system? :-)</div><div><br class=""></div><div>-Chris</div></body></html>