# Where is the implementation of \`dividedReportingOverflow\`?

**URL:** <https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246>\
**Category:** Standard Library\
**Created:** [April 8, 2021, 3:42pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246 "2021-04-08T15:42:03Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [April 8, 2021, 3:42pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/1 "2021-04-08T15:42:03Z")

</div>

I was just looking at [SR–3535](https://bugs.swift.org/browse/SR-3535) / [SR–5964](https://bugs.swift.org/browse/SR-5964) / [SR–11865](https://bugs.swift.org/browse/SR-11865), about how both `dividedReportingOverflow` and `remainderReportingOverflow` will fail to compile if the division is statically known to overflow (eg. the divisor is `0`, or both the divisor is `-1` and the dividend is `.min`).

So I wanted to take a look at the implementation of those methods (which I presume boils down to directly calling a built-in intrinsic operation), however I am unable to locate them.

When I search the Swift repo for `dividedReportingOverflow`, there are results in 6 files: 4 are tests, then Integers.swift which only declares the protocol requirements, and IntegerTypes.swift.gyb which produces the documentation comments but does not seem to contain the implementations.

So…where I can I find the implementations of `dividedReportingOverflow` and `remainderReportingOverflow`?

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [April 8, 2021, 3:55pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/2 "2021-04-08T15:55:46Z")

</div>

> [@Nevin](#):
>
> So I wanted to take a look at the implementation of those methods (which I presume boils down to directly calling a built-in intrinsic operation), however I am unable to locate them.

It does not call an intrinsic that reports overflow: as the comment states, there are no LLVM primitives for checking overflow of division operations, so we check manually, and only if there's no division by zero does it call the ordinary intrinsics for division operations.

> [@Nevin](#):
>
> When I search the Swift repo for `dividedReportingOverflow` , there are results in 6 files: 4 are tests, then Integers.swift which only declares the protocol requirements, and IntegerTypes.swift.gyb which produces the documentation comments but does not seem to contain the implementations.

IntegerTypes.swift.gyb does contain the concrete implementation of all standard library fixed-width integer types: you have to scroll past the documentation. Just search "ReportingOverflow" in that file.

Unless I'm mistaken, there is nothing about the implementation in that file which can solve SR-5964. The correct constant folding of the existing implementation should give `(0, true)` (or whatever the appropriate value is) instead of attempting to divide, so it's a constant folding bug.

---

<div class="post-metadata">

**Author:** ![nnnnnnnn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nnnnnnnn/32/264_2.png) [@nnnnnnnn](https://forums.swift.org/u/nnnnnnnn)\
**Post date:** [April 8, 2021, 4:05pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/3 "2021-04-08T16:05:42Z")

</div>

In case it helps, here's the de-gybbed implementation from an unsigned and a signed type:

```swift
extension UInt8 {
  @_transparent
  public func dividedReportingOverflow(
    by other: UInt8
  ) -> (partialValue: UInt8, overflow: Bool) {
    // No LLVM primitives for checking overflow of division operations, so we
    // check manually.
    if _slowPath(other == (0 as UInt8)) {
      return (partialValue: self, overflow: true)
    }

    let (newStorage, overflow) = (
      Builtin.udiv_Int8(self._value, other._value),
      false._value)
    return (
      partialValue: UInt8(newStorage),
      overflow: Bool(overflow))
  }
}

extension Int8 {
  @_transparent
  public func dividedReportingOverflow(
    by other: Int8
  ) -> (partialValue: Int8, overflow: Bool) {
    // No LLVM primitives for checking overflow of division operations, so we
    // check manually.
    if _slowPath(other == (0 as Int8)) {
      return (partialValue: self, overflow: true)
    }
    if _slowPath(self == Int8.min && other == (-1 as Int8)) {
      return (partialValue: self, overflow: true)
    }

    let (newStorage, overflow) = (
      Builtin.sdiv_Int8(self._value, other._value),
      false._value)
    return (
      partialValue: Int8(newStorage),
      overflow: Bool(overflow))
  }
}

```

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [April 8, 2021, 4:07pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/4 "2021-04-08T16:07:32Z")

</div>

> [@xwu](#):
>
> IntegerTypes.swift.gyb does contain the concrete implementation of all standard library fixed-width integer types: you have to scroll past the documentation. Just search "ReportingOverflow" in that file.

Ah, thanks, I made the classic mistake of searching for _the name of the method I wanted to find_. How silly of me.

> [@xwu](#):
>
> Unless I'm mistaken, there is nothing about the implementation in that file which can solve SR-5964. The correct constant folding of the existing implementation should give `(0, true)` (or whatever the appropriate value is) instead of attempting to divide, so it's a constant folding bug.

Hmm, I don’t understand this. The very first thing the implementation does is check:

```swift
if _slowPath(other == (0 as ${Self})) {
  return (partialValue: self, overflow: true)
}

```

How on earth does the compiler not simply inline this result when it sees a known-constant `0` as the argument?

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [April 8, 2021, 4:11pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/5 "2021-04-08T16:11:33Z")

</div>

> [@Nevin](#):
>
> How on earth does the compiler not simply inline this result when it sees a known-constant `0` as the argument?

Yup.

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [April 9, 2021, 3:08pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/6 "2021-04-09T15:08:29Z")

</div>

All right, having considered this further, I think that arithmetic overflow should _never_ be a compile-time error. The documentation is clear that operations like `+` and `/` will trap on overflow, and trapping is a _runtime_ behavior.

Moreover, Swift has consistently upheld the principle that trapping is \*safe\*, which is why trapping arithmetic is used by default in the first place. Therefore, if the compiler finds an arithmetic overflow while constant-folding, it may substitute an unconditional trap instruction, but there should be no compilation error.

• • •

According to the [changelog](https://github.com/apple/swift/blob/main/CHANGELOG.md), this behavior (raising a compile-time error for arithmetic overflow) was added on 2013-10-16.

I think that was a mistake.

Looking at the list of [arithmetic diagnostics](https://github.com/apple/swift/blob/main/include/swift/AST/DiagnosticsSIL.def#L301-L339), I’m pretty sure most of them should be removed entirely. Maybe a few should stay as warnings, but the point is that code which traps at runtime is _totally fine and ordinary and expected_.

If a programmer writes something that will trap at runtime, then that’s the behavior they should get: it ought to compile and run and trap, as expected.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [April 9, 2021, 3:55pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/7 "2021-04-09T15:55:05Z")

</div>

Essentially, you're saying that `42 / 0` should be explicitly permitted as an esoteric spelling of `fatalError`: I really don't see what use case could be served by _not_ informing the user of an unconditional trap when it's not explicitly spelled in code as such. What's the harm and what's the use case?

I'm also not sure I see much distinction between this and arguing, say, that notional copies of value type instances must always actually occur at runtime. The Swift compiler elides such behaviors pervasively; a different language may not, but the overall direction of Swift has been making things compiler evaluable as much as possible.

This is all still not addressing the real underlying issue of the bugs you're pointing out, which is that constant folding isn't producing the expected constant-folded result.

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [April 9, 2021, 4:12pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/8 "2021-04-09T16:12:09Z")

</div>

> [@xwu](#):
>
> Essentially, you're saying that `42 / 0` should be explicitly permitted as an esoteric spelling of `fatalError` : I really don't see what use case could be served by _not_ informing the user of an unconditional trap when it's not explicitly spelled in code as such. What's the harm and what's the use case?

The use-case is three-fold:

First, pedagogically, `42 / 0` has a defined behavior, so a programmer should be able to observe that behavior by running it.

Second, a programmer may write code which simplifies to `42 / 0`, but only when that code is unreachable.

For example:

```swift
func foo(_ n: Int) -> Int {
  if n < 10 {
    return 5
  } else {
    return 42 / n
  }
}

foo(0)

```

Third, as a principle, trapping is safe. The compiler should not prevent code from compiling simply because it will trap.

Of note, the code may do other things prior to trapping, and the language contract requires that the program must actually do those things before it crashes.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [April 9, 2021, 4:28pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/9 "2021-04-09T16:28:06Z")

</div>

> [@Nevin](#):
>
> Of note, the code may do other things prior to trapping, and the language contract requires that the program must actually do those things before it crashes.

That is a good point. Does Swift actually produce an error in such a scenario as you illustrate above with `foo(0)`?

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [April 9, 2021, 4:31pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/10 "2021-04-09T16:31:03Z")

</div>

> [@xwu](#):
>
> Does Swift actually produce an error in such a scenario as you illustrate above with `foo(0)` ?

I just rewrote the `dividedReportingOverflow` logic a little bit.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [April 9, 2021, 4:33pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/11 "2021-04-09T16:33:14Z")

</div>

> [@Nevin](#):
>
> I just rewrote the `dividedReportingOverflow` logic a little bit.

You'll need to actually flip the `<` to a `>` to make your example actually lead to a division by zero. I just tried this in Playgrounds and encounter a runtime error, not a compile-time error, so this is not an issue _even with a reachable divide-by-zero_ in user code afaict. I certainly agree that, if it becomes an issue, then it needs to be addressed.

[Edit: I just re-read your post and see your point about _unreachability_: yes, that's basically a reformulated version of the constant folding bug involving `dividedReportingOverflow`, and it needs to be fixed, but the same issue does not seem to impact user code modeled after that function: in Playgrounds, I correctly get no error at all with your example as written.]

Again, the `dividedReportingOverflow` bug you mention is a problem with constant-folding that needs to be solved. But I don't evidence of how that translates into demonstrating a _design_ problem here: in the general case, Swift doesn't seem to prohibit users from calling a function with a constant which causes an unconditional runtime trap but after performing other work that can't be elided. Again, I agree that if it did so, it should not.

* * *

As to your other points:

> [@Nevin](#):
>
> First, pedagogically, `42 / 0` has a defined behavior, so a programmer should be able to observe that behavior by running it.

I don't buy this argument for the same reason, as I said, that it's not distinguishable from notional copies: Pedagogically, `let x = y` is a copy, so a programmer should be able to observe that behavior by running it: but no, Swift can elide such copies and does so pervasively.

> [@Nevin](#):
>
> Second, a programmer may write code which simplifies to `42 / 0` , but only when that code is unreachable.

See above, that is the point about the constant folding bug that needs to be solved for `*ReportingOverflow` that doesn't seem to apply to user-written code.

> [@Nevin](#):
>
> Third, as a principle, trapping is safe. The compiler should not prevent code from compiling simply because it will trap.

No, it should not, and it does not--when the trap is spelled `fatalError`. But I _do_ think it's fine (even desirable) that the compiler should require all unconditional traps to be spelled obviously as such, not as a mathematical operation or some other function call.

> [@Nevin](#):
>
> Of note, the code may do other things prior to trapping, and the language contract requires that the program must actually do those things before it crashes.

See above, yes agree vigorously that Swift should not stop the user from writing such things.

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [April 9, 2021, 4:44pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/12 "2021-04-09T16:44:46Z")

</div>

> [@xwu](#):
>
> Again, the `dividingReportingOverflow` bug you mention is a problem with constant-folding that needs to be solved.

The constant-folding is _correct_. The code really does include a line equivalent to `42 / 0`. The problem is that this produces a compile-time error, instead of simply substituting a trap instruction.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [April 9, 2021, 4:48pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/13 "2021-04-09T16:48:15Z")

</div>

> [@Nevin](#):
>
> The constant-folding is _correct_ . The code really does include a line equivalent to `42 / 0` . The problem is that this produces a compile-time error, instead of simply substituting a trap instruction.

No, the constant-folding is _incorrect_. In `dividedReportingOverflow`, the actual division should never be reached with a denominator of 0, so how can it be correct to fold that into a compiler error?

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [April 9, 2021, 4:48pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/14 "2021-04-09T16:48:53Z")

</div>

> [@xwu](#):
>
> how can it be correct to fold that into a compiler error?

It is correct to fold it into a _division by zero_.

It is incorrect to turn _division by zero_ into a compiler error.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [April 9, 2021, 4:50pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/15 "2021-04-09T16:50:12Z")

</div>

> [@Nevin](#):
>
> It is correct to fold it into a _division by zero_ .

I do not understand. When given a zero denominator, no division by anything should take place. Why would it be correct to fold it into a division by anything?

---

<div class="post-metadata">

**Author:** ![lukasa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lukasa/32/1232_2.png) [@lukasa](https://forums.swift.org/u/lukasa)\
**Post date:** [April 9, 2021, 4:52pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/16 "2021-04-09T16:52:31Z")

</div>

This line of argument is not productive. It doesn't matter what optimisation pass triggers the diagnostic, and the fact that an optimisation pass triggers the diagnostic is not the problem.

What is clear is that the compile error is wrong, and the reason it is wrong is that this is not an unconditional trap but a _conditional_ one. The compiler should only emit a diagnostic for a statement that is provably going to trap at compile time if it can exhaustively prove that the statement will trap. The compiler cannot prove that here, and so it should remain silent.

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [April 9, 2021, 4:54pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/17 "2021-04-09T16:54:01Z")

</div>

> [@xwu](#):
>
> I do not understand. When given a zero denominator, no division by anything should take place. Why would it be correct to fold it into a division by anything?

Division by zero has a defined behavior in Swift: it is guaranteed to trap at runtime.

---

<div class="post-metadata">

**Author:** ![lukasa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lukasa/32/1232_2.png) [@lukasa](https://forums.swift.org/u/lukasa)\
**Post date:** [April 9, 2021, 4:58pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/18 "2021-04-09T16:58:32Z")

</div>

Specifically, my argument is this:

```swift
func foo(n: Int) -> Int {
    return n / 0 // Should fail to compile, will always trap.
}

func bar(n: Int) -> Int {
    if n % 2 == 0 {
        return n / 0 // Should fail to compile, will trap for all n that can enter this branch
    } else {
        return n / 2
    }
}

func baz(n: Int) -> Int {
    if n % 2 == 0 {
        return n + 1 / n // Must compile, will only trap for some inputs that enter this branch
    } else {
        return n / 2
    }
}

func boz(n: Int) -> Int {
    if n != 0 {
        return 5 / n // Must compile, will never trap for any n that can enter this branch
    } else {
        return 5
    }
}

baz(0) // Iff baz's definition is available, should fail to compile as this will unconditionally trap.
boz(0) // Must compile, an example of the bug being discussed here

```

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [April 9, 2021, 5:06pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/19 "2021-04-09T17:06:47Z")

</div>

> [@lukasa](#):
>
> What is clear is that the compile error is wrong, and the reason it is wrong is that this is not an unconditional trap but a _conditional_ one. The compiler should only emit a diagnostic for a statement that is provably going to trap at compile time if it can exhaustively prove that the statement will trap. The compiler cannot prove that here, and so it should remain silent.

Agree; I thought that was what I expressed in my line of argumentation? If not, that is what I mean :)

---

<div class="post-metadata">

**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\
**Post date:** [April 9, 2021, 5:07pm UTC](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246/20 "2021-04-09T17:07:19Z")

</div>

Those examples should at most warn.

They should all compile, since they exercise defined behavior.

[Next page](https://forums.swift.org/t/where-is-the-implementation-of-dividedreportingoverflow/47246.md?page=2)