[swift-evolution] Compiler Optimization of Optional-returning Functions followed by '!'

[Tony Allevato]

On Thu, Jan 19, 2017 at 2:17 PM Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi all,
>
> 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.
>
> Is this possible?
>
>
> 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.


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.

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.

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?

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?



> 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.
>
> It should also have a good effect on runtime performance for any place in
> code where a function result is immediately force unwrapped...
>
> Thanks,
> Jon
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170119/a7cf9aed/attachment.html>