[swift-evolution] typed throws

[Dave Abrahams]

on Fri Aug 25 2017, John McCall <rjmccall-AT-apple.com> wrote: 
 
>> On Aug 25, 2017, at 12:18 PM, Dave Abrahams via swift-evolution 
>> <swift-evolution at swift.org> wrote: 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. 
> 
> Them's fighting words. :) 

The correct term, John, is “fightin'”

-Crustee
 
> John. 
> 
>> 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 
>> _______________________________________________ swift-evolution 
>> mailing list swift-evolution at swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 

-- 
-Dave