[swift-evolution] [Pitch] Typed throws

[Matthew Johnson]

> On Feb 27, 2017, at 5:01 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> on Mon Feb 27 2017, Matthew Johnson <matthew-AT-anandabits.com> wrote:
> 
>>> On Feb 27, 2017, at 4:20 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>>> 
>>> 
>>> I'm sorry, I don't see any substantive difference, based on what you've
>>> written here, between this feature and const.
>> 
>> Let me give it one more shot and then I’ll drop it.  :)
>> 
>> Const is viral because if an API does not declare its arguments const
>> it cannot be used by a caller who has a const argument.  
> 
> Unless the caller casts away const, thus erasing information that was
> previously encoded in the type system.

Yes, of course.

> 
>> It is required in order to make an API as generally useful as
>> possible.
>> 
>> Typed errors are not viral in this way because no callers are
>> prevented from calling an API regardless of whether it declares error
>> types or just throws Error like we have today.  
> 
> Unless the caller can recover (which is *very* rare) or it catches and
> rethrows one of the errors *it* declares, thus erasing information that
> was previously encoded in the type system.

I view this as being fundamentally different than casting away const.  Casting away const says “I know better than the types”.

Converting an error to a different type is extremely different.  It much more similar to any other kind of value wrapper a library might create in order to shield its users from being coupled to its implementation details / dependencies.  This is not a way *around* the type system in the sense that casting away const is.  It is a way of *using* the type system (hopefully) to your advantage.



> 
>> Pressure to declare error types in your signature in order to make
>> your function as generally useful as possible does not exist.  Each
>> function is free to declare error types or not according to the
>> contract it wishes to expose.
>> 
>> An argument can be made that community expectations might develop that
>> good APIs should declare error types and they could be considered
>> viral in this sense because any API that is simply declared `throws`
>> is dropping type information.  But I think this overstates the case.
>> The community appears to be very sensitive to the problems that can
>> arise when error types are too concrete, especially across module
>> boundaries.  I think we can learn to use the tool where it works well
>> and to avoid it where it causes problems.
>> 
>>> 
>>> -- 
>>> -Dave
>> 
> 
> -- 
> -Dave