[swift-evolution] Remove Failable Initializers

[Howard Lovatt]

Not that I personally use failable initializers, but aren't they needed to
interact with Obj-C which returns nil to indicate failure from initializers?

  -- Howard.

On 3 March 2016 at 09:27, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

> I haven’t used a single failable initialiser ever since the try! command
> was added, as that gave the same convenience as force unwrapping and
> eliminated the need for big try/catch blocks if you didn’t expect an
> exception, with try? likewise making it easy to detect that any exception
> occurred, without caring about what it was.
>
> So I’d probably say that failable initialisers are unnecessary now;
> they’re a tiny bit cleaner for simpler failable initialisers (one type of
> failure), but it’s probably not worth keeping as a language feature when it
> comes up so rarely (at least in my experience).
>
> On 2 Mar 2016, at 21:11, James Campbell via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Given that we now have error handling and availability checks does it make
> sense to have Failable Initializers which date back to Swift 1.1?
>
> Take this model
>
> struct MyModel {
>
> let someProperty
> let anotherProperty
> }
>
> Lets say we have a Initializers for this structure that takes a JSON
> structure and returns an i.
>
> We could guarantee that it always returns an instance but then we have to
> populate this data with dummy values if the JSON is missing values.
>
> I could make these properties optional to reflect that the JSON was
> missing information but I would be making the structure mutable which adds
> complexity. On-top of that I wouldn't be able to tell if the property is
> nil due to a lack of a value or a bug causing certain JSON information to
> be missing.
>
> So lets look at the alternatives with a non-guranteed system, well we
> have Failable Initializers. If any of the properties are missing, we should
> return nil.
>
> Well we have this issue:
>
> MyModel(json)
>
> It isn't clear that this is fallable compared to a traditional initializer
> unless swift was update to, meaning we may forget to handle the nil case:
>
>  *MyModel?(json)*
>
> This isn't all that is wrong with this approach, if this method does a lot
> of steps to create the object and fails (Like parsing an object from JSON).
> Returning nil but we have no idea why, it makes it easy to introduce
> silently failing errors.
>
> Its true some classes may do this when ran on a older version of iOS but
> with avaliabilty checks, this use case is irrelevant.
>
> So what about throwing an error?
>
> It forces us to handle it failing to initialize for some reason.
>
> - If we forget to handle the error, the app won't be allowed to continue
> with this corrupted data - and the error will be informative as it forces
> us to create an ErrorType.
> - If we want to ignore this object and convert the error to nil we can
> still use *try? *(For example in a Chat application you could ignore
> corrupted messages).
> - In these cases where we ignore the error using *try?* it makes it super
> obvious we are ignoring an error and it should be easy to that error
> causing it to fail by using *try! *
> - On the whole it encourages us to not return nil and to return useful
> error codes which we can handle, what if one of the reasons it failed to
> parse is something we could recover from? If we return nil we will never
> know.
> - And it reduces the amount of mutability in swift.
>
>
> *___________________________________*
>
> *James⎥Head of Trolls*
>
> *james at supmenow.com <james at supmenow.com>⎥supmenow.com
> <http://supmenow.com/>*
>
> *Sup*
>
> *Runway East *
>
> *10 Finsbury Square*
>
> *London*
>
> * EC2A 1AF *
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160303/dabb7f8e/attachment.html>