> On Feb 19, 2017, at 1:32 PM, Anton Zhilin <antonyzhi...@gmail.com> wrote: > > Now that I think about it, generic throws does not exactly cover rethrows. > Firstly, rethrows has semantic information that function itself does not > throw—it would be lost. > Can you elaborate further on what you mean by this?
> Secondly, rethrows allows a function with multiple throwing function > parameters to become non-throwing iff all the arguments are non-throwing. > How would you express it with generics? > In the proposal, in this case you are required to provide a non-generic > supertype of all used error types. This type can’t just turn into Never > automatically. > This is a very good question. I’m curious if Joe has a solution that doesn’t require introducing any additional features into Swift. The answer I would like to see (that won’t happen in Swift 4) is to adopt some of the ideas in my value subtyping manifesto, including structural unions (that *do not* expose any members, even if there are members that all types have in common). All you would be able to do with such a union is convert from one of its constituent types to the union type and cast back down to one of the constituent types. Having unions like that would very elegantly solve the problem of a function that needs to throw more than one type. It also covers the case you bring up: `Never | Never | Never` would be the exact same type as `Never`. You would never write out `Never | Never | Never` of course, but in a generic context it’s important that we be able to spell it that way and have it collapse to a simple unordered set of its constituent types. Use of these structural union types would be discouraged in most cases, but they would be very powerful and useful in specialized contexts. Error handling is one of those contexts. Another is at the boundary of a system when you need to accept a heterogenous collection of a small, fixed set of types (as is discussed in the thread about open and public protocols). > One solution would be to retain rethrows as an additional attribute. > It would help with semantic information, and resulting error will be able to > turn into Never as a special case—now that we know, that this function > doesn’t throw that error itself. > I'm curious to hear Joe’s thought on this. It’s possible this would be a necessary bridge solution until we have something more permanent as I described above. > 2017-02-19 0:16 GMT+03:00 Martin Waitz <t...@admingilde.org > <mailto:t...@admingilde.org>>: > > > > >> Am 18.02.2017 um 17:37 schrieb Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >> >> Thank you for taking the time to put this proposal together Anton! I really >> want to see typed throws make it into Swift 4. This will be a very nice >> feature to have. >> >> I noticed that you included Joe Groff’s idea of replacing `rethrows` by >> making every function have an error type which is by default `Never` for >> non-throwing functions and `Error` for throwing functions that do not >> specify an error type. >> >> I want to urge you to consider updating the proposal to take this direction >> now rather than later. This is a breaking change which means the longer we >> wait the harder it is to justify. In fact, I think incorporating the >> breaking change could increase the chances of it being accepted for Swift 4. >> Without that it is a purely additive change and those are not being given >> priority in the Swift 4 release. > > Seconded. > With typed throwing function parameters, it makes a lot of sense to be able > to specify the rethrown type, based on the function given as parameter. > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
