+1 for keeping failable initializers. Error handling should be reserved for errors and not be used for control flow or logic.
-Thorsten > Am 27.12.2015 um 18:11 schrieb Chris Lattner via swift-evolution > <swift-evolution@swift.org>: > >> On Dec 27, 2015, at 5:22 AM, Manfred Lau via swift-evolution >> <swift-evolution@swift.org> wrote: >> I just found that the design of failable initializer is redundant in Swift >> 2. Because native error handling already has been introduced in Swift 2, and >> failable initializer indeed could be achieved by following codes: > > I’d be opposed to removing failable initializers. Failable inits introduce a > symmetry into the language for initializers, which make them possible to do > (almost) all of what you can do with a normal method. This capability is key > for them to be able to replace “factory” static methods, which allows Swift > to offer a consistent initialization pattern for clients of types. > > If we forced people to use error handling for anything that could return nil, > then things like String to Int conversions would most likely not use > initialization syntax. > > Besides that, over use of error handling waters it down and makes it less > valuable in itself. For more information on this, please see the design > discussion for error handling: > https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst > > -Chris > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
