on Thu Jun 09 2016, John McCall <rjmccall-AT-apple.com> wrote: >> On Jun 9, 2016, at 12:59 PM, Dave Abrahams <[email protected]> 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 >>>> <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
