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.
My point is that, as an opinionated language, Swift rejects certain options
such as one-line `if` statements without braces. One consideration for
proposals is whether it fits with the direction of the language, and the
larger point here is that "having the capability to choose based on
preference" is not one of the aims of Swift.
From what I've gleaned from this list, a successful proposal nearly always
takes the form: "Currently, we have option A. However, A has the following
problems 1, 2, and 3. Here is option B, which solves these problems. Thus,
B is superior to A and I propose to replace A with B." I have seen very few
successful proposals (have there been any?) take the form: "Currently, we
have option A. However, some prefer B. Therefore, I propose that Swift
should have both A and B."
If Swift doesn’t allow warnings to be suppressed, then what is
@discardableResult as an example.
The annotation has semantic meaning, namely that the result is intended to
be discardable and the function can be called solely for its side effects.
It does not exist for the purpose of making warnings go away; rather, it is
what makes warnings about discarded results even possible.
Put another way, if Swift did not have that annotation, it is difficult to
imagine that it would produce warnings about discarded results at all. Note
how there is no compiler flag to suppress warnings about discarded results
specifically. Nor, by design, does there exist a compiler flag to suppress
any specific category of warnings.
I don’t find your last argument of it being a control flow statement as
persuasive.
The point is that `guard` being different from other statements is
deliberate. When you see `guard`, you know that control is being
transferred out of the scope before the closing brace. That is a feature,
not a bug. Without that feature, it'd just be a synonym for `if !(...)`.
There are many ways of transferring control out of the scope, including the
calling of any function annotated @noreturn. Therefore, you must write down
which one you choose.
···
On Mon, Jun 20, 2016 at 10:48 PM, Yarden Eitan <yarneo@gmail.com> wrote:
On June 20, 2016 at 8:40:17 PM, Xiaodi Wu (xiaodi.wu@gmail.com) wrote:
On Mon, Jun 20, 2016 at 10:04 PM, Yarden Eitan via swift-evolution < > swift-evolution@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@icloud.com) wrote:
Le 20 juin 2016 à 02:30, Yarden Eitan via swift-evolution < >> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution