[swift-evolution] use standard syntax instead of "do" and "repeat"

[Andrew Duncan]

> 
>> 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.