> On Jan 3, 2016, at 2:08 AM, Andrew Duncan via swift-evolution > <[email protected]> wrote: > > >> >>> There are large classes of programs where you can know you don’t care >>> exactly where a failure happens, e.g. (most init functions, all pure >>> functions, any function that doesn’t break invariants). In these cases >>> marking every statement or expression that can throw is just noise. Try >>> writing some serialization/deserialization code where the underlying stream >>> can fail to see what I mean; you’ll have “try” everwhere, and it adds >>> nothing to comprehensibility or maintainability. Personally I would like >>> to be able to label the function itself and not have to introuce a scope, >>> but IMO being able to create “try blocks” would be a welcome addition and >>> would even match the common case in blocks with catch clauses, where being >>> aware of the exact line where the error was generated is typically not >>> useful. >> >> That's a really interesting idea, but I don't think it's what the poster was >> suggesting. It sounded to me like he was merely saying “let's make the Swift >> error system look like my favorite language's exception system". > > I agree with Brent’s assessment of the OP. However that doesn’t mean that > Dave does not have a good point. Here is some code from a recursive descent > parser. (More correctly: the recognizer. Omitting the AST-building stuff.) > > func recognizeHandler() throws { > try accept(.on) // .on is an enum tag for the token for the > ‘on’ keyword. > try recognizeName() > try recognizeFormalParamSeq() > try accept(.newline) > try recognizeCommandSeq() > try accept(.end) > try recognizeName() // Later Visitor pass checks that names match. > try accept(.newline) > } > > There is a lot more where that came from.
Exactly. The natural response from framework designers is to find more ways to support writing entire functions as a single expression. At the limit, you end up with http://www.boost.org/doc/libs/1_60_0/libs/phoenix/doc/html/phoenix/modules/statement.html. > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
