[swift-evolution] typed throws

[Dave Abrahams]

on Fri Aug 18 2017, Joe Groff <swift-evolution at swift.org> wrote:

>> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> Essentially, you give Error a tagged-pointer representation to allow
>> payload-less errors on non-generic error types to be allocated
>
>> globally, and then you can (1) tell people to not throw errors that
>> require allocation if it's vital to avoid allocation (just like we
>> would tell them today not to construct classes or indirect enum
>> cases) and (2) allow a special global payload-less error to be
>> substituted if error allocation fails.
>> 
>> Of course, we could also say that systems code is required to use a
>> typed-throws feature that we add down the line for their purposes.
>> Or just tell them to not use payloads.  Or force them to constrain
>> their error types to fit within some given size.  (Note that
>> obsessive error taxonomies tend to end up with a bunch of indirect
>> enum cases anyway, because they get recursive, so the allocation
>> problem is very real whatever we do.)
>
> Alternatively, with some LLVM work, we could have the thrower leave
> the error value on the stack when propagating an error, and make it
> the catcher's responsibility to consume the error value and pop the
> stack. We could make not only errors but existential returns in
> general more efficient and "systems code"-worthy with a technique like
> that.

That's how the best C++ unwiding mechanisms work already.  I always
thought it was off the table because we were wedded to the idea that
throwing functions are just effectively returning a Result<T> normally
under the covers, but if not, so much the better!

-- 
-Dave