[swift-evolution] An implicit return for guard

[Yarden Eitan]

The one line ‘if’ was just a known example of having the capability to
choose based on preference, and is not the core of this issue.
If Swift doesn’t allow warnings to be suppressed, then what is
@discardableResult as an example.
I don’t find your last argument of it being a control flow statement as
persuasive.


On June 20, 2016 at 8:40:17 PM, Xiaodi Wu (xiaodi.wu at gmail.com) wrote:

On Mon, Jun 20, 2016 at 10:04 PM, Yarden Eitan via swift-evolution <
swift-evolution at swift.org> wrote:

> I agree that by having different implicit ending statements (i.e.
> break/return/etc.) based on context makes it more complicated and less
> intuitive. Having said that, I do think that an implicit ‘return’
> with/without a warning (rather than an error), gives people the opportunity
> to either exclude or include the ‘return’ statement if they wish. This give
> the developers the optionality to choose what is the better code design
> based on their personal preference (like one liner ‘if’s with or without
> brackets). I do think that if there is a warning, it should also have the
> option to be suppressed.
>

Swift, by design, does not permit if statements without braces. It also, by
design, does not have optional warnings.


>
> If you think the ‘return’ statement has to be stated, then why don’t we
> enforce a ‘return’ statement at the end of void functions?
>

A `guard` statement is a control flow statement. It indicates that you are
prematurely exiting the scope, and therefore by design it requires you to
explain how you intend to do so.


> ‘guard’ should be treated and recognized in a way that ‘return’ is
> obvious, like void function endings. I agree that because it is a new
> thing, it might take time for people to see it as obviously as that.
>
> Looking at the previous requests for this, it seems like it is a pain
> point for several developers who see it redundant as most of their “guard”s
> use the same “return” or “return nil” statement.
>
> I think this current solution gives both ends the needed flexibility.
>
> Yarden
>
>
>
> On June 20, 2016 at 5:29:17 PM, Dany St-Amant (dsa.mls at icloud.com) wrote:
>
>
>
> Le 20 juin 2016 à 02:30, Yarden Eitan via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> ...
>
> 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.
>
>
> A 'guard' in a loop can commonly be used with either 'continue' or
> 'break', the compiler would not be able to guess your intent. And whatever
> default would be selected, it would be the wrong one for many scenarios.
>
> The 'return' is an important keyword which, I think, should not be
> obfuscated as one often need to quickly find all exit point of a function,
> when debugging/analyzing code.
>
> 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 you bring the consistency card, I would be more on the page of making
> 'break' mandatory and explicit in the 'switch'.
>
> Dany
>
> 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”) } ).
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160620/eb94a48e/attachment.html>