[swift-evolution] Marking sort and sorted with rethrows

[Dave Abrahams]

on Thu Jun 09 2016, John McCall <rjmccall-AT-apple.com> wrote:

>> On Jun 9, 2016, at 12:59 PM, Dave Abrahams <dabrahams at apple.com> wrote:
>> on Thu Jun 09 2016, John McCall <rjmccall-AT-apple.com> wrote:
>> 
>>>> On Jun 9, 2016, at 9:04 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>>> on Wed Jun 08 2016, Brent Royal-Gordon <brent-AT-architechies.com <http://brent-at-architechies.com/>> wrote:
>
>>>> 
>>>>>> I'm not sure that these ideas are consistent with the Swift
>>>>>> error-handling philosophy, which IIUC is very consciously designed *not*
>>> 
>>>>>> to support things like file- and database-backed Collections.  My
>>>>>> understanding is that if you have something like that, you're not
>>>>>> supposed to throw errors on failure, but instead find some alternative
>>>>>> means of error handling.  These cases seem very much in the same
>>>>>> ballpark.
>>>>> 
>>>>> I'm not talking about the Collection itself being backed by a file,
>>>>> but rather the instances inside it being backed by a file. 
>>>> 
>>>> Those amount to the same thing.  If instances can be backed by a file,
>>>> subscripting needs to be able to throw, and therefore practically every
>>>> generic function (or protocol extension method) on Collection would also
>>>> need to be marked as throwing.  When Swift error handling was designed,
>>>> it was decided that these cases were out-of-scope.
>>> 
>>> Right.  It would be simple to change core library protocols to permit operations
>>> to throw, but then every use of an algorithm over those protocols would throw.
>>> This is the sort of problem that we address with 'rethrows', but that's quite a bit
>>> more complex to apply to protocol conformances because you need to be more
>>> specific about which requirements, exactly, will cause you to rethrow.  
>> 
>> Can you show an example?  It seems simple to me: if you're going to
>> possibly rethrow you can use any requirements that might throw, and if
>> you're not going to rethrow then you can't.
>
> Right, but we don't have a way to talk about whether individual
> requirements or even conformances might throw.  It's not obvious that
> something as coarse-grained as "a conformance is non-throwing if every
> throwing requirement of the protocol and everything it inherits is
> satisfied by a non-throwing function" is actually good enough to
> express the constraints we want to express, 

In terms of expressivity, it *seems* to me that it would work out.  What
use-case are you concerned about?

> especially if we ever want to allow programmers to add additional
> (defaulted) requirements in protocol extensions.

Isn't that easily handled by limiting such Post-hoc defaulted
requirements to be nonthrowing or rethrows?

-- 
Dave