[swift-evolution] Marking sort and sorted with rethrows

[Dave Abrahams]

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

>> On Jun 20, 2016, at 9:57 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>> 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?
>
> In general, places where we have a "large" protocol and only one cluster of
> functionality can throw for a particular conformance.  For example, maybe only
> writes to a collection can throw.

I think when there's a significant difference in capability like that,
you tend to end up with a protocol refinement, such as
Collection/MutableCollection.  That ought to be enough to handle the
issue.

>
>
>>> 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?
>
> I think the rule would be that they would have to match the throwing-ness of the
> primary conformance.  I'm just saying that it would become a restriction on the
> expressivity of additional requirements.
>
> John.

-- 
Dave