[swift-evolution] Remove Failable Initializers

Kyle Sherman kyledsherman at gmail.com
Wed Mar 2 18:04:41 CST 2016


It seems to me that Haravikk’s example shows that you can handle the case of “string to int” with the error handling model just fine instead of having the failable initializers. I have found that failable initializers really don’t fit in well with Swift’s strict initialization rules (which I think are great). Every time I tried to use them I always had to make sacrifices with having an implicitly unwrapped optional or optional when I shouldn’t.

I think using the error handling model in combination with try? would be simpler and would lead to better code.

> > On 2 Mar 2016, at 23:07, Chris Lattner via swift-evolution<swift-evolution at swift.org(mailto:swift-evolution at swift.org)>wrote:
> > On Mar 2, 2016, at 1:11 PM, James Campbell via swift-evolution<swift-evolution at swift.org(mailto: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?
> > 
> > Our error handling schema (https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst#kinds-of-error) defines how error conditions are handled, and one important class of them (e.g. the "string to int" case) is best modeled as returning an optional.This works really well in practice for functions/methods in general.
> Could you give an example of why failable is the better fit here? To me the following two statements are identical:
> 
> let a = FailableType()
> let b = try? ThrowableType()
> 
> Except that in the latter case the try? is more explicit about what is happening (and that it can fail), and I have the option of catching the error to find out more about what went wrong. With some optimisation it should be possible for try? to be just as efficient as a failable initialiser I think.
> 
> That said, the failable initialiser could have the same explicit call syntax if it required a trailing question-mark, e.g:
> 
> let a = FailableType()?
> 
> As currently the only indicator is on the initialiser declaration itself. Still, when it comes to debugging I’ve found it very useful to force myself to use error handling instead, as it means I have to give reasons for why something failed, which can make it easier to track issues when they do arise._______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 


More information about the swift-evolution mailing list