<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 Mar 9, 2016, at 12:35, David Owens II 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=""><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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 9, 2016, at 12:02 PM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span 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; float: none; display: inline !important;" class="">I have to admit that initialization in Objective-C not only had the downside of being more cumbersome, but also the advantage of being simpler and more lightweight.</span></div></blockquote></div><br class=""><div class="">It is more cumbersome because it's significantly more powerful and tied to a class-hierarchy. That power also makes it "unsafe". Like most recent languages, Swift has gone the route of combining both allocation and initialization into one unifying concept. This is primary source of the init() constraints, limitations, and complexity. There's a lot to get right when your stance is that a type must be fully initialized before returning it to the caller.</div></div></div></blockquote><br class=""></div><div>This is not correct. Even if Swift had separated allocation and initialization, you would still have all of the "constraints, limitations, and complexity". It's the full initialization that forces this, not the combination with allocation.</div><div><br class=""></div><div>Every rule Swift enforces was a "rule" in Objective-C; you were just free to ignore it there. Between safety and convenience, Swift chooses safety. That said, I'm/we're still hoping to come with simpler, improved initialization rules. (I should really post my summary of problems with the current model somewhere. It probably doesn't cover <i class="">all</i> the problems, but it's a good starting point for discussion.)</div><div><br class=""></div><div>Additionally, from earlier:</div><div><br class=""></div><div><div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Unfortunately, Swift decided to make init() a special case thing. It's also the only function type that has special rules around accessing properties, the only one that cannot be named differently, the only one that has special rules around recursing or forwarding to other init() calls, and many other special rules and considerations. </div></div></blockquote><br class=""></div><div>I disagree with most of this. Property and subscript accessors, deinitializers, and closure expressions all have different rules from plain old 'func' (which itself behaves differently as a type member vs. top-level). Objective-C makes all of these things methods, which is very uniform but causes problems where they <i class="">should</i> differ in behavior.</div><div class=""><br class=""></div></div>Jordan</body></html>