[swift-evolution] An implicit return for guard

[Yarden Eitan]

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.

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? ‘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”) } ).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160620/1eed9920/attachment.html>