[swift-evolution] Marking sort and sorted with rethrows
John McCall
rjmccall at apple.com
Mon Jun 20 12:25:31 CDT 2016
> 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.
>> 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.
More information about the swift-evolution
mailing list