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

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

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

> On 3 Jan, 2016, at 10:51, David Waite wrote: > > One possible approach if it was desirable to not have this used arbitrarily > in place of do+try, and to avoid looking too much like exception syntax: > instead define rethrows blocks: > > func

[swift-evolution] Declaring a function that always returns nil

It should be possible to declare a function that returns only nil, and have its return type be substitutable for any function that returns and Optional. This is something like having a bottom type but not really. What I mean is: func returnsNil(errCode:Int) -> nil { logError(errCode) //

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

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

Re: [swift-evolution] [Pitch] Guarding on enum values

In fact, I feel the same way too. I have definite views about indefinite pronouns. When I am teaching, I studiously avoid “it”, “this”, and “that”: at any given instant half the students have wandering minds, and if they miss the referent, they get lost. My old HyperTalk habits must be

Re: [swift-evolution] [Pitch] Guarding on enum values

alls. If I >> consistently return a .Fail(ErrorCode) or .Succeed(ASTNode) from each >> method, I just pass on the Result in case of .Fail, or use it in case of >> .Succeed. >> >> >>> On 23 Dec, 2015, at 15:35, Joe Groff <jgr...@apple.com> wrote: >>

Re: [swift-evolution] [Pitch] Guarding on enum values

. If I consistently return a .Fail(ErrorCode) or .Succeed(ASTNode) from each method, I just pass on the Result in case of .Fail, or use it in case of .Succeed. > On 23 Dec, 2015, at 15:35, Joe Groff <jgr...@apple.com> wrote: > > >> On Dec 23, 2015, at 10:16 AM, Andrew Dunca