[swift-evolution] [Pitch] Typed throws
matthew at anandabits.com
Mon Feb 27 17:12:14 CST 2017
> 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
>> 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.
More information about the swift-evolution