[swift-evolution] Remove Failable Initializers

Austin Zheng austinzheng at gmail.com
Tue Mar 8 15:49:52 CST 2016

If the argument is that taking away "init?()" is going to force Swift users
to embrace the One True Path of Error Handling, I don't think that's going
to happen. The more likely outcome is that people are going to wrap
throwable initializers in factory methods returning optionals, and throw
away whatever error returns.

Not that this is a bad thing, mind you. In a lot of cases my application
does not care why an operation failed, only that it did. This isn't because
I'm lazy, but because the recovery path for each potential type of error is
exactly the same. In this case I don't care about which error was thrown,
but I often do care about the ability to compose I get from nil.

As for the sample code, there is absolutely nothing wrong with it IMO. The
contract to me for 'asInt' reads "return an Int if an item exists at
`index` and, if that item exists, it can be represented as an Int". I think
it's instructional to look at how Dictionary<T?> works - if you try to
extract an element you get a double optional. This isn't a type system bug,
it's completely intentional. The internal optional indicates whether an
extant element was Some or None, and the external optional indicates
whether or not the element existed in the dictionary to begin with. If I
were writing that `asInt` function and I really needed to make the
distinction between "invalid index" and "not an integer string", I'd use
either that same double optional pattern, or make the function throws. If I
didn't care, I'd use the optional representation.


On Tue, Mar 8, 2016 at 1:09 PM, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

> On 8 Mar 2016, at 15:26, Thorsten Seitz <tseitz42 at icloud.com> wrote:
> Am 08.03.2016 um 11:07 schrieb Haravikk via swift-evolution <
> swift-evolution at swift.org>:
> Just because someone opts to use error handling over a failable
> initialiser doesn’t mean they have to go overboard on the detail of their
> errors; it’s entirely possible to pick a reasonable middle-ground.
> And it is entitely possible to just use an optional. If you prefer to use
> error handling over failable initializers, fine, just do so, but don't
> force it on others who are perfectly happy with the option to use
> optionals, too.
> It’s not an issue of ideology but of redundancy; the failable initialiser
> does nothing that error handling can’t do just as easily, the only
> difference is that instead of returning nil, you throw an appropriate error.
> The few extra characters are hardly going to kill you, while a thrown
> error (with common ones available for simplicity) can describe what went
> wrong in more detail than just “something went wrong”. Point is that we
> have two ways of achieving the same goal, but error handling encourages
> developers to think more about what type(s) of error to throw at each
> point; even just simple error types with no further detail can provide more
> information simply by being different, for example if you have a
> NonNumericError vs EmptyStringError types, the errors themselves tell you
> all you’re likely to need to know (hopefully there’d be a good set of
> common types).
> There are also some cases where failable initialisers can have subtle
> errors, for example, can you tell me where I might run into problems with
> the following:
> struct MyType {
>     let elements:[String]
>     func asInt(index:Array<String>.Index) -> Int? {
>         if self.elements.indices.contains(index) {
>             return Int(self.elements[index])
>         }
>         return nil
>     }
> }
> _______________________________________________
> 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/20160308/561d64fc/attachment.html>

More information about the swift-evolution mailing list