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

[Chris Lattner]

> On Jan 3, 2016, at 6:36 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I agree that requiring this is not likely to result in improved error handling and thus is not a strong argument in favor of it.
>>> 
>>> IMO the purpose of requiring “try” to be stated explicitly is that it arguably makes code more readable.  It is immediately clear which functions can throw and which cannot.  You don’t need to look up the signature of every function called to determine this. My experience thus far has been that I have really appreciated the requirement that throwing expressions be explicitly marked. 
>> 
>> As a default it’s great.  Not having a way to opt out of individual marking for a whole block or function—because you know you’re not breaking any invariants, so which functions can throw is irrelevant, and not having a way for the compiler deduce these regions (e.g. known pure functions)—is the problem.  The recognizer code posted in an earlier message is a perfect example.  If there *was* some code where it was really important to notice failure points, you’d miss it. 
> 
> I feel like I must be missing something here.  If we are able to mark the whole block with try I don’t see how we would notice any really important failure points.  They would not be marked anywhere in the source:
> 
>   func recognizeHandler() throws {
>     try {
>         accept(.on)        // .on is an enum tag for the token for the ‘on’ keyword.
>         recognizeName()
>         recognizeFormalParamSeq()
>         accept(.newline)
>         recognizeCommandSeq()
>         accept(.end)
>         recognizeName()    // Later Visitor pass checks that names match. 
>         accept(.newline)
>     }
>   }


Indeed.  Also, FWIW, I’d argue that maybe the root problem here is that this code should not be using Swift’s error handling constructs in the first place.  An enum (or other approach) may be more appropriate.  Swift’s error handling design is intentionally driven by the idea that you shouldn’t use it if “everything throws” - in this situation, the sugar benefits of error handling are intentionally outweighed by the weight of the try keywords everywhere.  This is meant to force the balance over to using more manual techniques.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160103/afcfabe9/attachment.html>