proposal: unsafe: add Unreachable

[josharian]

When optimizing code, I often run up against cases in which the compiler is missing a key fact. Sometimes it could but does not infer it; sometimes there’s no reasonable way for the compiler to know.

In those cases, there is nothing to do but drop to assembly. (In normal code you could write if !x { panic }, but in many of these cases, that is prohibitively expense.)

I propose that we add unsafe.Assume. It accepts a boolean expression. The expression is typechecked but never evaluated. However, the compiler may assume that it evaluates to true when compiling other code.

I imagine the most common uses would be things like unsafe.Assume(p != nil), unsafe.Assume(0 <= i && i < len(s)), and unsafe.Assume(x < 64), for nil checks, bounds checks, and shift amounts, respectively.

[jimmyfrasche]

What happens if the assertion does not hold?

[josharian]

The compiler may generate code that does all sorts of awful things. It is decidedly unsafe.

[cherrymui]

To me, this sounds like "Assume". I would think "Assert" means if the assertion fails, the program crashes (more like the C assert function).

[josharian]

@cherrymui thanks, proposal updated.

[ianlancetaylor]

Another approach would be unsafe.Unreachable(). The compiler can assume that no code path will lead to a call of that function. This effectively lets you write

    if p == nil {
        unsafe.Unreachable()
    } else {
        // Here the compiler knows that p != nil.
    }

and then at some point during code generation the compiler removes the p == nil test and the Unreachable call.

[josharian]

@ianlancetaylor I like it. One nice thing about that is that it mirrors the not-unsafe way to write it:

if p != nil {
  panic("unreachable")
}

becomes

if p != nil {
  unsafe.Unreachable()
}

And the specification is simpler.

The only downside I see is that it doesn't fit on one line. :P It also doesn't scream unsafe at me the way unsafe.Assume does, even though they are expressively equivalent...but I guess the package name suffices for that.

[jimmyfrasche]

What happens if you ask the compiler to assume something it knows is false? Like something that reduces to

x := -1
unsafe.Assume(x > 0)

[josharian]

What happens if you ask the compiler to assume something it knows is false?

Then you're in UB world: It depends on the compiler and the details. I'm guessing that in practice, with cmd/compile right now, probably not too much. With gccgo, you probably start spewing random numbers until you generate the kubernetes code base.

[jimmyfrasche]

If the compiler doesn't know that x <= -1, sure UB, but, if the compiler has proved that x <= -1 and you ask it to assume that x > 0, it seems like it should error out.

[josharian]

it seems like it should error out.

Perhaps optionally? I think that a compiler that simply ignored unsafe.Unreachable/unsafe.Assume should be spec-compliant.

[seebs]

I like this a lot for my code, I'm terrified of what happens if other people have it.