<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">TLDR version, I would check with the developers of Swift web servers (Vapor, Kitura, etc) if this is their actual plan also to re-work their webserver using actors and processes instead of threads. I’m not writing a webserver myself, so that is what it should come down to. Right now, if you unwrap an optional, it crashes their entire server. It just seems thoughtless to me.</div> <br> <div id="bloop_sign_1490224176028339968" class="bloop_sign"></div> <br><p class="airmail_on">On March 22, 2017 at 7:07:04 PM, Elijah Johnson (<a href="mailto:ejrx7753@gmail.com">ejrx7753@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap:break-word"><div></div><div>
<title></title>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
Hi,</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">
Note that this thread has branched off a bit, so my latest proposal
and the “head” of this thread can be found at <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034189.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034189.html</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">
<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">
<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">
Can you give an example of this corruption which would be
exploitable in a web server context? An example where, having
caught the force-unwrap or other precondition fatalError, that the
web server would face more danger from continued execution that it
would loose by crashing?</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">
The optional has been triggered, the request has been stopped, and
incoming requests are going to a new process, but there are a few
threads open still finishing what they were doing - I’d like to see
a good example of the danger caused by a real “inconsistency”. Lets
assume also that all objects shared between threads are Swift
objects and not “UnsafePointers”, which is a very fair assumtion
for a web server. Java even allows native access and they don’t
even crash there. I’m sorry, but I completely fail to grasp the
danger as being > crashing.</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">
As for “hard to debug” errors, providing a stack trace and logging
it, stopping the one request that caused it, is sufficient for
debugging a production environment.</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">
<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">
<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’d be interested to know who these web server developers (ex.
Kitura, Vapor) are targeting without any form of crash handling and
if they read these threads. It really limits the pool of developers
more so than on apps because a single crash on the app ie
equivelant to a failed request, not a crashed web server. I realize
you are not competing with Java, but I do not see yet the
compelling reason for no crash handling.</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">
The “actors” with thread pool and proccesses is one idea, but I
think these servers are aiming also for speed and scaleability -
don’t know if they would accept this model. I know that it does get
used, and do work for a company that uses it on their backend (just
plain Java, not sep. processes). Their front-end probably runs like
a pre-fork server, but Java is so stable that there is simply no
need for that.</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>
<br>
<div id="bloop_sign_1490219697181918976" class="bloop_sign"></div>
<br>
<p class="airmail_on">On March 22, 2017 at 1:03:42 PM, Joe Groff
(<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>) wrote:</p>
<blockquote type="cite" class="clean_bq">
<div style="word-wrap:break-word" class="">
<div><span><br class=""></span>
<div>
<blockquote type="cite" class="">
<div class=""><span>On Mar 6, 2017, at 4:20 PM, Elijah Johnson via
swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</span></div>
<span><br class="Apple-interchange-newline"></span>
<div class="">
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><span>Hi,</span></div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><span><br class=""></span></div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><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="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><span><br class=""></span></div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><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="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><span><br class=""></span></div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><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="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><span><br class=""></span></div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><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="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><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="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><span>3. Some styles of coding just can’t work without
force-unwrap.</span></div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><span><br class=""></span></div>
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px" class=""><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>
</blockquote>
<span><br class=""></span></div>
<div><span>The long-term vision here is to have some form of
finer-grained fault isolation ("actors" being the buzzword for that
we tend to throw around). As others noted, using `!` is intended to
indicate that it is *impossible* for a value to be nil at a certain
point, and that the programmers screwed up if the value is nil at
that point. The only safe thing to do in a situation the
programmers didn't plan for is stop execution; anything else is
just going to lead to harder-to-debug, potentially-exploitable
inconsistencies further removed from the original problem. With
actors, it could become possible for that crash to only take down
an isolated subprogram, and give a supervisor subprogram an
opportunity to gracefully wind down the process—on clients, this
might mean saving application state so that the app can be cleanly
restarted, and on the server, this might mean closing the process's
accept socket but still letting existing requests complete before
restarting the potentially-compromised process. There's still a
tradeoff here from a defense-in-depth standpoint, since any
requests running in the same process have the potential to corrupt
each other's state. Swift's crash-early design hopes to minimize
the opportunity for corruption to leak.</span></div>
<div><span><br class=""></span></div>
<div><span>-Joe</span></div>
<span><br class=""></span></div>
</div>
</blockquote>
</div></div></span></blockquote></body></html>