[swift-evolution] Remove Failable Initializers

[David Owens II]

> On Mar 9, 2016, at 1:15 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>> On Mar 9, 2016, at 12:35, David Owens II via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Mar 9, 2016, at 12:02 PM, Tino Heth <2th at gmx.de <mailto:2th at gmx.de>> wrote:
>>> 
>>> 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.
>> 
>> 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.
> 
> 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.

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.

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.

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.

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.

> 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 all the problems, but it's a good starting point for discussion.)

It would be great to see.

> Additionally, from earlier:
> 
>> 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. 
> 
> 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 should differ in behavior.

Sure... not all people are happy about those differences =). Regardless, but those are relatively minor compared to how init() works.

-David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160309/06c04b02/attachment.html>