On Thu, Jan 12, 2017 at 7:34 PM, Greg Parker <[email protected]> wrote:
> > On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull <[email protected]> wrote: > > > Also, ‘try’ is still required to explicitly mark a potential error > propagation point, which is what it was designed to do. You don’t have > ‘try’ with the variants because it is by default no longer a propagation > point (unless you make it one explicitly with ’try’). > > > If this is quite safe and more convenient, why then shouldn't it be the > behavior for `throws`? (That is, why not just allow people to call throwing > functions without `try` and crash if the error isn't caught? It'd be a > purely additive proposal that's backwards compatible for all currently > compiling code.) > > > Swift prefers that potential runtime crash points be visible in the code. > You can ignore a thrown error and crash instead, but the code will say > `try!`. You can force-unwrap an Optional and crash if it is nil, but the > code will say `!`. > > Allowing `try` to be omitted would obscure those crash points from humans > reading the code. It would no longer be possible to read call sites and be > able to distinguish which ones might crash due to an uncaught error. > > (There are exceptions to this rule. Ordinary arithmetic and array access > are checked at runtime, and the default syntax is one that may crash.) > FWIW, that was meant to be an argument a fortiori (well, ad absurdum, I suppose). If `throws!` is a good idea (whose purpose is to permit omission of `try!` at call sites), then how much nicer would it be if we could just do that with `throws`. It is, after all, technically source compatible. But it is not, I agree, such a good idea with `throws`, so I'm skeptical of its worth with the increased burden of new syntax. -- > Greg Parker [email protected] Runtime Wrangler > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
