This is exactly the kind of example I was thinking of. I think it's going to be uncommon, but it is nonetheless a source break.
Doug
2 Likes
The error conditions are explicitly documented. You should be getting DecodingError.typeMismatch in this case, which the API is documented as returning "if the encountered encoded value cannot be converted to the requested type" which is definitely the case you're interested in.
Tangentially, this also harkens back to my earlier point that I think it should be possible to specifically list enum values in what's thrown, not just whole enum types, as not every API is supposed to be able to throw every value from a given enum (and refactoring things into a distinct enum for each function, while a workaround, might prove a bit repetitive and tedious).
1 Like
I appreciate your humility but in your defence I don't think you did anything wrong, neither in what you wanted to do (simply know if a value existed but wasn't integer-compatible) nor how you tried to achieve that.
Would you blame yourself if you were using URL.init?(string:) to validate user input - based on whether it returns nil or not - and then in iOS 17 it stops doing that validation, always returning non-nil? I would hope not - that's clearly an ill-conceived, breaking change (and one that also violates both the old and the new documented behaviour of the initialiser, like your decoding case).
In my opinion (and we'll get meta about that in just a minute) it shouldn't matter whether it's the return value or the thrown error, the behaviour should be well-defined and stable (or at the very least have a good reason, and forewarning, for any breaking changes).
"Well-defined" can also mean intentionally opaque. The problem in this decoding case is that the code only says it throws any Error, but the documentation says it throws a specific type (DecodingError) and that type specifically enumerates the cases. If error typing were solely in code rather than in documentation, then there'd be no room for discrepancy. Either it does throw something specific - in which case it's completely unambiguous that it should follow that contract - or it throws an opaque (or otherwise limited) type and there's nothing you should do to try to further decipher that (maybe you could use runtime type introspection to deduce what it sometimes throws, based on ad-hoc testing, but then it would be all on you if those assumptions were later broken).
The Art of Errors
There's clearly a philosophical difference amongst folks in this thread. I like error conditions to be well-defined and precisely delineated, for example. Some folks think exceptions are opaque and should never be inspected at runtime, just logged (I presume?). And myriad variations in-between.
I'm not surprised by the diversity of opinions nor the existence of any given approach and I have no qualms about any of it - each to their own, we may each work in very different environments - but I am⌠disappointed to see folks trying to force a philosophy onto others.
It's been stressed in this proposal - quite rightly - that stronger typing needs to be opt-in and be easily ignored. I agree entirely, and I think it succeeds at that. No-one is required to take advantage of more precise error typing as callers or callees. Just like you can e.g. use Any for every function parameter in your Swift program if you want, without undue difficulty. But if someone made you use Any for all your parameters, I suspect you'd be pretty displeased, no?
Case Study: POSIX
As an example of an error-handling philosophy I find compelling, look at the POSIX APIs. A set of APIs designed to be widely used and to have to work in a predictable fashion across countless platforms, as the foundation for all applications. That's not a standard that every API ever made needs to be held to, but it's critical to some (like, say, Apple's Foundation library).
Look at the specification of the open function, for example. A set of error cases are clearly enumerated, covering all the known and likely problems (at the time of the API's specification) even though not exhaustive. That lets you know that e.g. if you try to create a new file and the file already exists you get EEXIST. You don't get "some non-zero code". You're never going to get EINVAL, or ENOTDIR, or any other code. You'll get EEXIST. And you are able to use that in your code to handle that case properly (e.g. by telling the user the file already exists and asking if they want to overwrite it - very different to how you would handle any other error case).
I want the ability to make APIs like that in Swift, as first class citizens of the language (i.e. statically type-checked and utilising exhaustiveness-checking in all respects, not just for parameters and non-error return values).
6 Likes
I may have missed it in the proposal and discussion so far, but what's the evolution story for existing protocols? I'm writing a new protocol that I'd like to keep simple using throws but I'd like to adopt typed throws with it ASAP as it leads to some nice API, especially when the error is Never.
public protocol WebSocketMessageSerializer {
associatedtype Output
associatedtype Failure = Error
func decode(_ message: URLSessionWebSocketTask.Message) throws -> Output
}
If I updated it for the newest compiler when typed throws is available, existing conformances will still work, right? I think the rules outlined say that, due to the equivalence between throws and throws(any Error), that it would line up just fine.
public protocol WebSocketMessageSerializer {
associatedtype Output
associatedtype Failure = Error
func decode(_ message: URLSessionWebSocketTask.Message) throws(Failure) -> Output
}
This is source (but not ABI) compatible, right?
It also seems like any conformers which currently have to manually set the Failure type to Never would then get automatic inference, right?
struct PassthroughWebSocketMessageDecoder: WebSocketMessageSerializer {
public typealias Failure = Never
public func decode(_ message: URLSessionWebSocketTask.Message) -> URLSessionWebSocketTask.Message {
message
}
}
This would become:
struct PassthroughWebSocketMessageDecoder: WebSocketMessageSerializer {
public func decode(_ message: URLSessionWebSocketTask.Message) -> URLSessionWebSocketTask.Message {
message
}
}
Question there is whether the manual typealias is equivalent to the inferred value. I'll hold off on shipping this publicly anyway (it won't work as a serializer until typed throws are available, as the Never case can't be propagated to my later processing without it), I just want to make sure I understand the evolution story here.
3 Likes
This is sort of where I was going with the @unknown catch idea earlier: have a way to specify a list of expected errors in the throws effect, and then allow all the expected errors to be caught exhaustively. This without necessarily disallowing unexpected errors (those not listed) from being thrown. It also allows the list of expected errors to change over time, similar to enums that can evolve, without causing issues for source or binary compatibility.
I suppose a variation of that would be listing expected enum cases in throws(...) rather than only expected types. In which case it would become some kind of list of patterns to check for, or some kind of error mask.
I don't see anything incompatible with the current proposal. They serve different purposes and can be implemented separately. But I suspect if they are added at the same time, people will be less tempted to use typed throws for the sole reason of having the compiler help you check for exhaustiveness.
1 Like
I missed that completely, and it's pretty funny. This is getting steadily further from the focus of the pitch, but I can't resist pointing out that this hasn't been true for at least the past two years of releases (iOS 15.4 and 16.4 both give dataCorrupted in this case).
As regards the pitch: IMO this reinforces the already-settled point that there are plenty of APIs where using error details for flow control, even if it is possible in terms of language features, is inadvisable.
Indeed. This proposal just doesn't go that far. Which I think is the right thing to do, despite my enthusiasm for one day taking this further. We don't have to go all-in at once, we can start with a more limited system and evaluate it before committing to next steps.
(plus there's a time aspect to this, in that Embedded Swift has overlapping needs which can be satisfied by the proposal as-is, so no need to delay that)
It's (genuinely) fascinating that we've looked at the same example and come to polar opposite conclusions in this regard. Can you elaborate w.r.t to your reasoning?
I see this particular API as adding detail in its error responses for debugging convenience, but the semantic contract is in a bit an awkward liminal state: it theoretically exists (there are enum cases, there is documentation of what they mean) but practically speaking it's not reliable (it's not at all typical usage to use these cases for flow control; if you try, you'll find it's been incorrect for several years and apparently nobody noticed or cared).
Given how unreliable the contract is in practise, we seem to split our responses: you'd like better tools for enforcing the contract, whereas it makes me question whether the contract should ever have been expressed in the first place. It's really a different animal to something like a file-system access error, where it's fully expected that the API caller is going to make flow-control decisions based on error details.
2 Likes
Iâm so excited to NOT have âthrowingâ variants of everything going forward 
Having the option for typed throws is a no-brainer for me. It will do wonders for protocols and generic code needing to abstract over errors. (Something weâve seen a lot of lately!)
There still seems to be a fair amount of resistance in to this pitch in the other thread, and I feel thatâs because the idea has somehow been undersold. Seeing more of the powerful things we can do with typed throws in protocols will, I think, be what pushes it over the edge for people.
Overall Iâm super impressed with the proposal document. Itâs very thorough, and sure taught me a few things!
I wonder if the proposal could highlight more of the protocol-related enhancements, like with AsyncSequence? It felt like the âgood stuffâ was buried way at the bottom.
Iâm excited to get a beta implementation out for everyone to play around with! Congrats and thank you to everyone involved!
5 Likes
I disagree with you on that specific point, but nonetheless I now understand where you're coming from. Thanks for explaining that so clearly!
1 Like
Yeah, I also feel like this proposal enables much more good stuff than it does harm.
The changes to AsyncSequence and the likes alone would be huge.
However, it's a bit sad that we're only getting typed throws now (but fingers crossed that we are in fact getting them), when the ABI is already locked. There is so much API in the standard library that could benefit from this, but cannot because it would change the ABI.
Lengthy example
E.g. even Sequence/IteratorProtocol could benefit from this. If it were defined like this (we'd probably need default primary associated types though):
public protocol IteratorProtocol<Element, Failure /* = Never */> {
associatedtype Element
associatedtype Failure: Error = Never
mutating func next() throws(Failure) -> Element?
}
public protocol Sequence<Element, Failure /* = Never */> {
associatedtype Element
associatedtype Failure: Error = Never
associatedtype Iterator: IteratorProtocol
where Iterator.Element == Element, Iterator.Failure == Failure
func makeIterator() throws(Failure) -> Iterator
// other requirements...
}
We could have a throwing LazyMapSequence:
public struct LazyMapSequence<Base: Sequence, Element, Failure /* = Never */> {
public typealias Elements = LazyMapSequence
internal var _base: Base
internal let _transform: (Base.Element) throws(Failure) -> Element
internal init(_base: Base, transform: @escaping (Base.Element) throws(Failure) -> Element) {
self._base = _base
self._transform = transform
}
}
extension LazyMapSequence {
public struct Iterator {
internal var _base: Base.Iterator
internal let _transform: (Base.Element) throws(Failure) -> Element
public var base: Base.Iterator { return _base }
internal init(
_base: Base.Iterator,
_transform: @escaping (Base.Element) throws(Failure) -> Element
) {
self._base = _base
self._transform = _transform
}
}
}
extension LazyMapSequence.Iterator: IteratorProtocol, Sequence {
public mutating func next() throws(Failure) -> Element? {
return _base.next().map(_transform)
}
}
extension LazyMapSequence: LazySequenceProtocol {
public __consuming func makeIterator() -> Iterator {
return Iterator(_base: _base.makeIterator(), _transform: _transform)
}
}
extension LazySequenceProtocol {
public func map<U, F>(
_ transform: @escaping (Element) throws(F) -> U
) -> LazyMapSequence<Elements, U, F> {
return LazyMapSequence(_base: elements, transform: transform)
}
}
This would finally allow throwing errors in a lazy map. The same would work for lazy filter as well of course. And this is only one example I could think of at the moment.
4 Likes
If we wanted to, we could use the current error ABI for typed errors in existing entry points. There might still be minor source-breaking effects to narrowing the error type of a function, but it's at least conceptually a compatible API change, like specifying a more specific return type.
4 Likes
While that could work, we cannot add typed throws to previously non-throwing APIs (like my LazyMapSequence example) without breaking ABI, right?
2 Likes
Not as is, but since the concrete types in those cases are not really intended to be directly used in source, we could at least supersede them with a new version of .lazy.map which creates a LazyMapSequence2 or something like that, while keeping the old entry point around for existing clients. Doing something like that would also be a great opportunity to make the lazy algorithms use opaque some Sequence<T> return types to internalize their implementation types.
6 Likes
I don't want to derail the thread too much into details, but that would only work if IteratorProtocol.next() allowed a typed throw which it does currently not. So, if I'm not mistaken, we would have to change IteratorProtocol and Sequence as well, so that we'd be able to create a new LazyMapSequence2 type that allows throwing.
2 Likes
Hi all,
The current proposal has a rather complicated section dedicated to rethrows semantics, which tries to update rethrows in a manner that doesn't break any existing code while still getting the benefits of typed throws when code has opted into typed throws.
Now, the vast majority---perhaps nearly all!---rethrows functions will only ever throw one of the errors that was thrown by one of the closure arguments. The standard library is full of such rethrows functions, like map:
func map<T>(_ body: (Element) throws -> T) rethrows -> [T] {
var result: [T] = []
for element in self {
result.append(try body(element))
}
return result
}
This function only ever throws the exact error thrown from body. With typed throws, we don't even need the notion of rethrows to express this, because the function can be expressed as carrying the error type from its closure parameter to itself:
func map<T, E>(_ body: (Element) throws(E) -> T) throws(E) -> [T]
ABI considerations aside, this change is source-compatible and has the added benefit of working nicely with closures that have typed throws.
So, what if instead of the complicated rethrows semantics I proposed, we turn rethrows into syntactic sugar for introducing a generic parameter for each of the closures marked throws, and then the function itself has throws(errorUnion(E1, E2, ..., En)) (where each Ei is the error type for a closure parameter). For the vast majority of rethrows functions, this would imply no change at all, and we'd have a simpler feature.
Now, this would break rethrows functions that are doing some kind of translation or wrapping of the
error thrown by one of the closure arguments, i.e.,
func translateRethrown(f: () throws -> Void) rethrows {
do {
try f()
} catch {
throw GenericError(message: "\(error)") // error: GenericError is not an E
}
}
This function would become ill-formed under the simplification I'm talking about. There's a way to get the old semantics, but it's obscure:
func translateRethrownWithHack(f: () throws -> Void, _ dummy: () throws(any Error) -> Void = { }) rethrows {
do {
try f()
} catch {
throw GenericError(message: "\(error)") // okay, the rethrown error type is `any Error`
}
}
The translation here looks like this:
func translateRethrownWithHack<E>(f: () throws(E) -> Void, _ dummy: () throws(any Error) -> Void = { }) throws(errorUnion(E, anyError))
Note that errorUnion is only currently used for exposition. Since one of the inputs is any Error, this is equivalent to what we have with today's rethrows:
func translateRethrownWithHack<E>(f: () throws(E) -> Void, _ dummy: () throws(any Error) -> Void = { }) throws(anyError)
Naturally, we would only be able to make such a change to rethrows with a major language version. But the result is a simpler language, where rethrows is just syntactic sugar for something typed throws naturally expresses.
Big thanks to @Slava_Pestov for suggesting this simplification.
Thoughts?
Doug
11 Likes
Big +1 on this from me â it makes the whole concept of rethrows more transparent.
One thing I'm wondering about is the default value for AsyncIteratorSeqeunce's Failure parameter. If it were set to Never instead of any Error, I think there's a couple of advantages.
public protocol AsyncIteratorProtocol<Element, Failure> {
associatedtype Element
associatedtype Failure: Error = Never
mutating func next() async throws(Failure) -> Element?
}
Firstly, it seems both clearer and more consistent for conforming types that throw to always specify the second generic parameter while types that don't throw can omit it.
let throwingSeq = MySequence<Int, any Error>
let otherThrowingSeq = MySequence<Int, MyError>
let seq = MySequence<Int>
Secondly, it seems that this may open up the possibility of introducing typed throws to Sequence types:
public protocol IteratorProtocol<Element, Failure> {
associatedtype Element
associatedtype Failure: Error = Never
mutating func next() throws(Failure) -> Self.Element?
}
As the new Failure parameter is additive, all existing opaque Sequence types will still be specified as designed, and as all existing Sequence types are missing a throws clause the compiler can hopefully infer that their Failure type is Never.
3 Likes
Wouldn't this remain available instead of a hack?
func translateRethrown<E>(f: () throws(E) -> Void) rethrows(any Error)
Because this is much clearer.
It also enables rethrowing an unrelated but specific error type:
func translateRethrown<E>(f: () throws(E) -> Void) rethrows(TranslationError) {
do {
try f()
} catch {
throw TranslationError(message: "\(error)")
}
}
which your hack doesn't support.
3 Likes