<div dir="ltr">On Mon, Jun 20, 2016 at 10:48 PM, Yarden Eitan <span dir="ltr"><<a href="mailto:yarneo@gmail.com" target="_blank">yarneo@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">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.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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."</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">If Swift doesn’t allow warnings to be suppressed, then what is @discardableResult as an example.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"> I don’t find your last argument of it being a control flow statement as persuasive. </div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><div><p>On June 20, 2016 at 8:40:17 PM, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>) wrote:</p> <blockquote type="cite"><span><div><div></div><div>
<div dir="ltr">On Mon, Jun 20, 2016 at 10:04 PM, Yarden Eitan via
swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">
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. </div>
</div>
</blockquote>
<div><br></div>
<div>Swift, by design, does not permit if statements without
braces. It also, by design, does not have optional warnings.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<br></div>
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">
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?</div>
</div>
</blockquote>
<div><br></div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">
‘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.</div>
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<br></div>
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">
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. </div>
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<br></div>
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">
I think this current solution gives both ends the needed
flexibility.</div>
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<span><font color="#888888"><br></font></span></div>
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<span><font color="#888888">Yarden</font></span></div>
<div>
<div><br>
<div>
<div style="font-family:helvetica,arial;font-size:13px">
<br></div>
</div>
<br>
<p>On June 20, 2016 at 5:29:17 PM, Dany St-Amant (<a href="mailto:dsa.mls@icloud.com" target="_blank">dsa.mls@icloud.com</a>)
wrote:</p>
<blockquote type="cite">
<div dir="auto">
<div>
<div><span><br></span></div>
<div>
<div><span><br></span></div>
<span>Le 20 juin 2016 à 02:30, Yarden Eitan via swift-evolution
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> a écrit :<br>
<br></span></div>
<blockquote type="cite">
<div style="font-family:Helvetica,Arial;font-size:13px;color:rgb(0,0,0);margin:0px">
<span>...</span></div>
<div><span><br></span></div>
<div><span>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.</span></div>
</blockquote>
<div><span><br></span></div>
<span><span style="background-color:rgba(255,255,255,0)">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.</span></span>
<div><span style="background-color:rgba(255,255,255,0)"><br></span></div>
<div><span style="background-color:rgba(255,255,255,0)">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.</span></div>
<div><br></div>
<blockquote type="cite">
<div>
<div>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.</div>
</div>
</blockquote>
<div><br></div>
If you bring the consistency card, I would be more on the page of
making 'break' mandatory and explicit in the 'switch'.
<div><br></div>
<div>Dany<br>
<div><br>
<blockquote type="cite">
<div>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”) } ).</div>
<div><br></div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote>
</div>
<br></div>
</div>
</div></div></span></blockquote></div></div></div></div>
</blockquote></div><br></div></div>