`const if` to supress instantiation/codegen of unreachable branches

[the8472]

Currently there's a suboptimal interaction between const asserts and const generics.

A more general function that is valid for all N cannot call a function that asserts at compile time that N fulfills some conditions even if the call is on a branch that's dead for the invalid N.

I.e. this does not compile:

#![feature(inline_const)]

// method in std
fn method_with_precondition<const N: usize>() {
    const { assert!(N > 0) };
}

// user method, no way to opt out of asserts for N = 0
fn generic_caller_method<const N: usize>() -> fn() {
    if N > 0 {
        panic_on_zero::<N>
    } else {
        || {} // fallback
    }
}

fn main() {
    let _fun = foo::<0>();
}

error[E0080]: evaluation of `panic_on_zero::<0>::{constant#0}` failed
 --> src/main.rs:5:13
  |
5 |     const { assert!(N > 0) };
  |             ^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: N > 0', src/main.rs:5:13
  |
  = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

This blocks / requires unpleasant choices in several T-libs features that want to check for N != 0 or similar constraints:

• Tracking Issue for Iterator::array_chunks rust#100450
• Tracking Issue for slice::array_chunks rust#74985
• Tracking Issue for slice::array_windows rust#75027
• Tracking Issue for split_array rust#90091 - although this one needs generic_const_exprs before we can even worry about callers
• Tracking Issue for Iterator::map_windows (feature iter_map_windows) rust#87155

If const-eval in the dead branches is expensive it might also help compile perf.

There are efforts (rust-lang/rust#99682) to move monomorphization-time errors to check time and also apply those checks to dead code (rust-lang/rust#112879), which will make it even more difficult to discharge compile-time obligations imposed by callees.

Currently the language does not seem to have any way to select different code paths in generic contexts without also instantiating those paths. Even generic_const_exprs does not offer this unless it gets extended rust-lang/project-const-generics#26

Therefore it would be useful if we could write the case above as

fn foo<const N: usize>() -> fn() {
    const if N > 0 { 
        panic_on_zero::<N>
    } else {
        || {} // fallback
    }
}

so that panic_on_zero::<0> will never be instantiated.

[Jules-Bertholet]

I would note pattern types as an alternative; you could constrain an input const parameter with a pattern (eg const N: usize in 1..), and combine this with trait machinery to select an impl based on the value of the const:

#![feature(inline_const)]

fn panic_on_zero<const N: usize>() {
    const { assert!(N > 0) };
}

trait FooImpl<const N: usize> {
    const FN: fn();
}

impl<const N: usize in 1..> FooImpl<N> for () {
    const FN: fn() = panic_on_zero::<N>;
}

impl FooImpl<0> for () {
    const FN: fn() = || {};
}

fn foo<const N: usize>() -> fn() {
    <() as FooImpl<N>>::FN
}

fn main() {
    let _fun = foo::<0>();
}

[Lokathor]

That is significantly harder to understand/review.

[the8472]

That looks like the same kind of unification as the const expr issue that I linked to.

[oli-obk]

I'm a big proponent of pattern types, but I have to agree this is not a good use case for it.

On the topic at hand, do you want a generic_const_exprs like scheme where this shows up in where bounds and needs to have where bounds all the way up to where it is monomorphic? Or do you want this to be a post monomorphization error explicitly? Or well, in the case of the example, a way to avoid post monomorphization errors?

[the8472]

Oh, having the issue written like this (returning a function pointer) I now realize that anonymous consts + function pointers might help, if the optimizer plays along.

I.e.

fn foo<const N: usize>() -> fn() {
    const {
       if N > 0 { 
          panic_on_zero::<N>
       } else {
          || {} // fallback
       }
    } 
}

But this is not as ergonomic as a real const-if because it means callers needs to hide the dead branches inside functions that get selected by a const block.

At least the playground doesn't complain.

Edit: #3582 (comment) says that this will stop working in the future.

[Jules-Bertholet]

That is significantly harder to understand/review.

I fully agree, but if pattern types are added to the language for other reasons anyway, then perhaps the ergonomics improvement alone wouldn't justify a separate dedicated const if. (I'm not arguing for this claim, just raising the possibility.)

I would also note, that with pattern types as const generic parameters, much of what is now implemented as post-mono assertions could become pre-mono checks, eg:

// Now checked pre-mono
fn require_nonzero<const N: usize in 1..>() {}  

trait FooImpl<const N: usize> {
    const FN: fn();
}

impl<const N: usize in 1..> FooImpl<N> for () {
    const FN: fn() = require_nonzero::<N>;
}

impl FooImpl<0> for () {
    const FN: fn() = || {};
}

fn foo<const N: usize>() -> fn() {
    <() as FooImpl<N>>::FN
}

fn main() {
    let _fun = foo::<0>();
}

A hypothetical const match could then improve the ergonomics:

// Now checked pre-mono
fn require_nonzero<const N: usize in 1..>() {} 

fn foo<const N: usize>() -> fn() {
    const match N {
        N_1_PLUS @ 1.. => require_nonzero::<N_1_PLUS>,
        0 => || {},
    }
}

fn main() {
    let _fun = foo::<0>();
}

[Lokathor]

Well, once there's const match then there's not a strong argument against const if, since it would seem that const if is a strict subset of const match.

[the8472]

Imo that's just restating the problem. In this context pattern types are ~isomorphic to generic_const_exprs with
Conditional<{(1..).contains(N)}>. And here too impls may very well only exist for some pattern of N and not all N, meaning more-generic caller faces the same issue.
And const-match is the ~same solution to the problem.

[Jules-Bertholet]

Pattern types are ~isomorphic to generic_const_exprs with Conditional<{(1..).contains(N)}>.

The advantage of the pattern types approach specifically is that the compiler can do exhaustiveness, disjointness etc checking, so rust-lang/project-const-generics#26 is potentially tractable even for impls involving them. With arbitrary generic_const_exprs, you need a full SMT solver or post-mono errors

[oli-obk]

I think even if we come up with a perfect where bound based system, having an escape hatch that you explicitly need to opt into is good.

It may be easier on the compiler implementation side to require a const if expression to be of function pointer type and its branches to only be path expressions. So basically sugar for

#[rustc_arg_required_const(0)]
#[rustc_intrinsic]
fn const_if<A, R>(cond: bool, on_true: fn(A) -> R, on_false: fn(A) -> R) -> fn(A) -> R;

where, due to the magical nature of rustc_arg_required_const being an explicit hack (that we already have for legacy SIMD reasons) where the argument must be const, we can do expressions without triggering generic_const_exprs checks.

[the8472]

It may be easier on the compiler implementation side to require a const if expression to be of function pointer type and its branches to only be path expressions. So basically sugar for

#[rustc_arg_required_const(0)]
#[rustc_intrinsic]
fn const_if<A, R>(cond: bool, on_true: fn(A) -> R, on_false: fn(A) -> R) -> fn(A) -> R;

Would that mean less work for the compiler compared to #3582 (comment)

[oli-obk]

Would that mean less work for the compiler compared to #3582 (comment)

that only works because rust-lang/rust#112879 hasn't landed in forever because it's such a massive perf regression

[the8472]

I'll cite that as another reason to have const-if then.

[tgross35]

This seems like a component of something more generally usable, along the lines of Zig's comptime type operations. That is, if we support branching and pruning on const generics, it would be cohesive to allow behavior based on generic types (if T == u32 { ... }) - which we may or may not want.

Pattern types do indeed make selecting behavior more complicated, but something like a pattern type in the where bounds does seem more consistent with generic types if the intent is simply that compiling fails in certain conditions.

fn foo<const N: usize>() -> fn() 
where N == 0
{
    || {} // fallback
}