> On Jun 20, 2016, at 9:57 AM, Dave Abrahams <dabrah...@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 <dabrah...@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@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. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution