<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap:break-word"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Well, I think that it is far more ingrained into the language and its daily use than you might realize.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">At the very least, someone should correct the XCode warning that says (to paraphrase) “code does not comple, double click to insert optional here” and create some code-analysis warnings against the practice of forced unwrap where it can be replaced.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">I’ve been a full year with Swift now, and just a week or two ago I learned about this optional binding feature. You could say I’m not devoted enough, but I’ve not had any crashing issues, XCode just told me to insert force-unwrap and thats what I did.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">If this whole “force-unwrap” thing isn’t the intended way of doing things, that could be made a bit more explicit I think.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Here’s a screenshot of what I am referring to: <a href="https://snag.gy/dH6twR.jpg">https://snag.gy/dH6twR.jpg</a></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Says: Fix it: Insert !</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Should say: Fix it: Use optional binding.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Xcode might not be in the Swift evolution domain, but I think the idea of warnings for "unnecessary use of !” are.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">On March 6, 2017 at 9:47:04 PM, Austin Zheng (<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>) wrote:</div> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<div dir="ltr">Swift already is an unmanaged language, and is far
closer to C++ than Java. There is no equivalent to the CLR or JVM
and it is trivially easy to call into C code or the unsafe APIs and
do nearly anything that C can do with regard to direct access to
memory.
<div><br></div>
<div>The force-unwrap operator was never intended to model a
Java-style runtime exception. Instead, it is an assertion which
indicates a programmer logic error. The preferred way to handle an
optional at runtime has always been to use the
conditional-unwrapping functionality the language offers. The
correct way to report errors at runtime that aren't due to
programmer error is through the do-try-catch mechanism. Pervasive,
unnecessary use of '!' is a project management and/or developer
competence issue, and not something the language should go out of
its way to fix.</div>
<div><br></div>
<div>Sugaring 'if let' for programmer convenience is something on
the commonly rejected proposals list: <a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md">https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md</a></div>
<div><br></div>
<div>Regards,</div>
<div>Austin</div>
<div><br></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Mar 6, 2017 at 6:27 PM, Elijah
Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
Additionally, not discarding previous comments, one way the
language could be improved is by replacing (or rather augmenting)
optional binding with a faster syntax.</div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
ex.</div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
func test( name : String?, name2 :String? ){</div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
name! , name2! {</div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
// inside this block, “name” and “name2” are non-optional</div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
} else {</div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
// no forced unwrapping, just optional else
case</div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
}</div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
}</div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
Whereas the alternative (current optional binding), requires a
re-definition of variables and an additional “if” operator. Besides
the extra characters involved in typing and reading it, usually
variables have specific names that the user does not want to
augument.</div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
func test( name : String?, name2 :String? ){</div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
if let nameUnwrapped = name , let name2Unwrapped =
name2 {</div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
<br></div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
} else {</div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
}</div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
}</div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
<br></div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
func test( name : String?, name2 :String? ){</div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
guard let nameUnwrapped = name , let name2Unwrapped =
name2 else {</div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
<br></div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
}</div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
<br></div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
}</div>
</div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
<br></div>
<div id="m_2492479024697317942bloop_customfont" style="margin:0px">
The fact that we don’t need a “nameUnwrapped” variable (which is
unsightly and requires refractoring) is one thing that still makes
forced unwrapping still very much a necessary or common part of
Swift coding, even where it could be replaced with optional
binding.</div>
</div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<br></div>
<br>
<div id="m_2492479024697317942bloop_sign_1488852857050308864" class="m_2492479024697317942bloop_sign"></div>
<br>
<p class="m_2492479024697317942airmail_on">On March 6, 2017 at
7:20:40 PM, Elijah Johnson (<a href="mailto:ejrx7753@gmail.com" target="_blank">ejrx7753@gmail.com</a>) wrote:</p>
<blockquote type="cite" class="m_2492479024697317942clean_bq">
<div style="word-wrap:break-word">
<div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span>Hi,</span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span><br></span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span>I’ve been recently considering Swift on the server-side, and
there came up the question, “what happens when a null optional is
forcibly unwrapped?” and the answer was clearly that not only would
the request crash, but the entire server would also crash, since
the server itself is/would be also written in Swift.</span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span><br></span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span>I think that this highlights serveral weaknesses in Swift’s
“null safety” attempts. The first is that there needs to be a way
to isolate blocks of code so that a “null pointer exception” does
not crash the system. I think it is fair to say, in the language of
Java, that these are really “runtime exceptions” and for some
reason are being treated as segmentation faults would be in C/C++.
In my opinion, the existence of these things has the ability to
bring Swift down below Java and closer to an unamanged language.
Not really sure why it would ever be desireable, but in terms of
server-side programming, it is definitely a serious
issue.</span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span><br></span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span>Secondly, Swift’s “null safety” is really completely
undermined by these “force-unwrap” errors. I agree with the usage
of new language features like guard, optional binding, etc to
remove a null value, but I see this force-unwrap as extremely
pervasive for a lot of reasons:</span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span><br></span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span>1. When porting code from a C style language to Swift,
force-unwrap is needed to make the code work without
refractoring.</span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span>2. XCode itself reccomends this operator and when it is used
to satisfy a requirement, then it can be left in the
code</span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span>3. Some styles of coding just can’t work without
force-unwrap.</span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span><br></span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span>I don’t think the logic of making the consequences extreme
for making a mistake are a rational for making better coders. In
fact, I personally see the “force-unwrap” operator having very
great potential usage as a deliberate assertion exception - the
programmer demands that a certain value be non-null for execution
to continue, only there should be a proper scope and context where
these exceptions can propogate to. On debug modes, one might want
it to pause on the line, but for other uses, it should be caught
IMO - on regular code by the user, and inside dispatch blocks by
the queue itself. For a multithreaded app or server to exit, the
user should have to explicitly write exit(0), isn’t this the goal
of a managed language? Maybe in some cases, Apple will want the
program to crash, but if Swift is given an audience not just with
Apple hardware, then it should have more flexibility
IMO.</span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span><br></span></div>
<div id="m_2492479024697317942bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
<span>Elijah</span></div>
<div id="m_2492479024697317942bloop_sign_1488843525920942080" class="m_2492479024697317942bloop_sign"></div>
</div>
</div>
</blockquote>
</div>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote>
</div>
<br></div>
</div></div></span></blockquote></body></html>