<div dir="ltr"><div>Just a minor pitch here, based on user experience:</div><div><br></div><div>With SE-0104, the `addWithOverflow` family of arithmetic operators are not longer static, they have been renamed `addingReportingOverflow`, and their return type has been changed from `(T, Bool)` to `(partialValue: T, overflow: ArithmeticOverflow)`. `ArithmeticOverflow` is an enum with two cases, `overflow` and `none`.</div><div><br></div><div>This is a great improvement in terms of readability. However, having actually used these new functions, I&#39;m finding that `ArithmeticOverflow` is a step down in usability. Since `Bool` is not `RawRepresentable`, one must write out the comparison every time: `if overflow == .overflow`. There is nothing else one can do with an `ArithmeticOverflow` other than converting it into a `Bool`. It doesn&#39;t immediately seem terrible, but when working with these operations repeatedly (and, chances are that if you need such an operation, you don&#39;t need it just once) this quickly gets very cumbersome.</div><div><br></div><div>On the library side, every time an `ArithmeticOverflow` is returned, it actually makes use of an initializer that takes a `Bool` argument. In essence, with every call to a `*ReportingOverflow` function, a `Bool` is converted to an `ArithmeticOverflow`, returned, then converted by the user back into a `Bool`. From comments in the standard library, it appears that the compiler can&#39;t yet fully elide these operations either.</div><div><br></div><div>My pitch is threefold:</div><div><br></div><div>1. Change the return type to `(partialValue: T, overflow: Bool)` and eliminate the `ArithmeticOverflow` type.</div><div><br></div><div>2. Tweak the name to improve how it reads (it was a last-minute change in the first place) from `addingReportingOverflow` to `addingWithOverflowReporting`. This avoids the &quot;-ing -ing&quot; clash and eliminates the nonsensical interpretation of the phrase &quot;multiplied, reporting overflow by 42.&quot;</div><div><br></div><div>3. Separable from (1) and (2), consider making `Bool` a `RawRepresentable` type.</div><div><br></div></div>