On Sun, Jan 15, 2017 at 3:12 PM, Haravikk <swift-evolut...@haravikk.me> wrote:
> > On 12 Jan 2017, at 23:35, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > >> I really like swift’s error handling system overall. It strikes a good >> balance between safety and usability. >> >> There are some cases where it would be nice to throw errors, but errors >> are rarely expected in most use cases, so the overhead of ‘try’, etc… would >> make things unusable. Thus fatalError or optionals are used instead. For >> example, operators like ‘+’ could never throw because adding ’try’ >> everywhere would make arithmetic unbearable. But in a few cases it would >> make my algorithm much cleaner if I just assume it will work and then catch >> overflow/underflow errors if they happen, and resolve each of them with >> special cases. Or perhaps I am dealing with user entered values, and want >> to stop the calculation and display a user visible error (e.g. a symbol in >> a spreadsheet cell) instead of crashing. >> > > Unless I'm mistaken, there is a performance overhead for throwing > functions, and thus a much greater barrier to the use cases outlined above > is that the performance penalty for '+' would be unacceptable in any case, > whatever syntactic sugar you could come up with. > > > Just wanted to chime in on performance, but since operators should really > be inlined in most cases anyway I'm not sure there should be any > performance penalty; the compiler should just optimise it away such that it > basically becomes what it is now, the only case in which it would add a > penalty is if the optional try is actually used. > > > I really like this idea personally; I prefer it to using the > addWithOverflow() and similar methods, not that they're super burdensome, > but error handling feels like a better fit IMO. > `addWithOverflow()` gives you both the result and a flag; error handling would at most give you one of these two. If that's a common use case, it'd be an argument for a failable addition operator, but not a throwing one, since there is only one error that happens (overflow).
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution