<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 19, 2017 at 2:17 PM Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br class="gmail_msg">
<br class="gmail_msg">
I would like to propose an optimization to the compiler where, when a call to an optional-returning function is immediately followed by a ‘!’, we allow the compiler to generate an alternate version of the function where a trap replaces 'return nil’ and the function returns a non-optional result. This would save the build-up and tear-down cost of the optional.<br class="gmail_msg">
<br class="gmail_msg">
Is this possible?<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
The main reason I would want this is to be able to later propose moving our default array index handling to a safer optional-returning version. I know that a safe variant is on the horizon, but defaults really matter… especially with newcomers to the language. Array indexing should return an optional, forcing the programmer to deal with an out-of-bounds case appropriately.</blockquote><div><br></div><div>I've heard it argued on this list before, and I agree, that in most cases (i.e., those not involving user input, which should be sanity checked separately anyway) an out-of-bounds array index is essentially a precondition failure, not a legal program state that users need to proactively test.</div><div><br></div><div>I personally adopt a style where I try to avoid the use of ! unwraps as much as possible, so incurring those on every array access wouldn't improve the quality of my code.</div><div><br></div><div>In a world where we have an abstract index model, iterators, and for-each loops, is the problem of people accidentally accessing out-of-bounds elements really as severe as it used to be, to the point that we shouldn't simply require them to check the bounds before such operations where it might occur?</div><div><br></div><div>That being said, I like the idea of the optimization you describe above *in general*, but I would hope it wouldn't require a fully alternate version of the function to be generated—maybe the optimizer could handle it more generally. I haven't personally looked into it, but what's the overhead incurred by the optional build-up/tear-down?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Where the current behavior is desired, the access is immediately followed by a ‘!’ indicating the potential crash-point explicitly in code. Migration would simply add a ‘!’ after every array subscript access. The above proposal is meant to mitigate any performance issues from the change, because the generated function for the cases followed by ‘!’ would be identical to the current version.<br class="gmail_msg">
<br class="gmail_msg">
It should also have a good effect on runtime performance for any place in code where a function result is immediately force unwrapped...<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
Jon<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>