<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 1:15 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.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=""><br class=""><div class=""><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 class="">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></div></blockquote><div><br class=""></div><div>There are the rules for how types are instantiated and there are rules for how they are initialized, both have "constraints, limitations, and complexity". I agree that what I wrote conflated to the two issues together, and lead to a mostly ambiguous statement.</div><div><br class=""></div><div>Part of what I was referring the black-box that is allocation of and lifecycle management of types that we really have no control over today. For instance, I cannot tell Swift to create my object out of a specific data region that Iv'e created. I can pre-allocate, what is essentially an array of those types, but then I cannot use init() anymore to ensure that I have nice, clean instantiations. Of course, I can't call a shared `reset` either from the init(), so I end up with duplicated code.</div><div><br class=""></div><div>ObjC allowed us to implement these, maybe it wasn't safe or we won't supposed to, but it was useful. Similarly, we can do this in C or C++. Of course, these methods aren't "safe" as they don't guarantee us fully instantiated types. Like you said: trade-off between safety and convenience.</div><div><br class=""></div><div>If we get custom allocators, or something similar, then this goes a long way to solving many of those types of limitations for init(). Of course, there's still the other set of limitations and complexities for ensuring that a type is fully instantiated. This also probably requires some work around owned memory allocations in order to enable the safety that Swift is looking for.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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></div></blockquote><div><br class=""></div><div>It would be great to see.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Additionally, from earlier:</div><div class=""><br class=""></div><div class=""><div class=""><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 class="">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></div></blockquote><div><br class=""></div><div>Sure... not all people are happy about those differences =). Regardless, but those are relatively minor compared to how init() works.</div><div><br class=""></div><div>-David</div></div></body></html>