[swift-evolution] [Pitch] Minor adjustment to new FixedWidthInteger protocol

[Xiaodi Wu]

Just a minor pitch here, based on user experience:

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`.

This is a great improvement in terms of readability. However, having
actually used these new functions, I'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't immediately seem terrible, but when working
with these operations repeatedly (and, chances are that if you need such an
operation, you don't need it just once) this quickly gets very cumbersome.

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't yet fully elide these operations either.

My pitch is threefold:

1. Change the return type to `(partialValue: T, overflow: Bool)` and
eliminate the `ArithmeticOverflow` type.

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 "-ing -ing" clash and
eliminates the nonsensical interpretation of the phrase "multiplied,
reporting overflow by 42."

3. Separable from (1) and (2), consider making `Bool` a `RawRepresentable`
type.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170422/dab77848/attachment.html>