This has been suggested several times before. See the conversations below: http://article.gmane.org/gmane.comp.lang.swift.evolution/11563/
http://article.gmane.org/gmane.comp.lang.swift.evolution/6770/ On Mon, Jun 20, 2016 at 01:30 Yarden Eitan via swift-evolution < [email protected]> wrote: > Dear community, > > While using ‘guard’ with much appreciation, I noticed a few cases where I > would of hoped for better and more concise code. > > As of now, you receive a compiler error if your guard statement does not > provide an ending statement such as return/break/etc. at the end. > It is informative, but in many cases such a statement makes the code > repetitive and less concise. > > As an example of cases where there are multiple guards done sequentially > to avoid very nested and unclear ‘if's: > > guard let resp = response as? HTTPURLResponse else { > failure(…) > return > } > > guard let resp.statusCode == 200 else { > failure(…) > return > } > > guard let respData = data else { > failure(…) > return > } > > guard let res = parse(respData) else { > failure(…) > return > } > > success(…) > > As you can see in this example, while the different failures can (and > should) provide different information for completion, we always have to add > a repetitive return after them. > > My proposal is to allow for an implicit return when no ending statement is > provided. We could take this one step further and have the compiler aware > of it’s most inner scope and see if it is a while loop for example and > implicitly allow a break. But I think at least as a first step, by having > an implicit “return” we are saving the repetitiveness on many cases where > there are multiple guard statements and the return from them is obvious. > > This goes along the line of the Swift “switch” statement, which doesn’t > follow it’s predecessors and force a “break” but rather it is already > implicitly there. > > If this proposal is too much of a leap, an alternative is to allow an > implicit return but provide a warning (not an error). This warning can be > suppressed using an @implicitreturn prefix to the guard statement or > something along those lines (@implicitreturn guard a = b else { > print(“foo”) } ). > > Glad to hear your thoughts on the matter. > > Best, > Yarden > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
