<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: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 class=""><br class=""></div><div class="">-David</div></body></html>