functions as const parameters

[lcnr]

We currently forbid function pointers as const parameter types, so the following causes an error:

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

The reason we forbid this because comparing function pointers is not deterministic iirc.

Does this non-determinism only occur at runtime, and if so, are there any reasons why we must not allow function pointers as const param types? I think ctfe is fully deterministic wrt function pointers.

cc @oli-obk @RalfJung

[RalfJung]

So far the idea for comparing valtrees (on which const parameters should be based eventually) was to demand that valtree comparison agrees with PartialEq. That condition is easy to state and easy to understand.

With function pointers, valtree comparison is entirely incomparable to PartialEq: two function pointers can be equal at compile-time while being different at runtime, and vice versa. Basically, we'd entirely give up on any connection between the notion of equality used at compiletime and the notion of equality used at runtime. Isn't that enough of a problem to better not do this?

[lcnr]

two function pointers can be equal at compile-time while being different at runtime, and vice versa.

I forgot that the comp eq -> runtime neq direction also exists. If it were only comp neq -> rt eq this would have been acceptable to me.

I was thinking about this because afaik there isn't a way parameterize over behavior without using a trait or relying on type inference, so I think there's no way to do the following:

struct Foo<F: FnOnce()> {
   x: F,
}

fn concrete_foo() -> Foo<???> {
    Foo {
        x: some_function_or_closure
    }
}

As a small tangent, would it make sense to warn when comparing function pointers directly, explaining that it might not necessarily be deterministic?`If we change that to a deny by default in the far far future we could allow them as const param types.

[RalfJung]

would it make sense to warn when comparing function pointers directly, explaining that it might not necessarily be deterministic?

Maybe?

If we change that to a deny by default in the far far future we could allow them as const param types.

I don't think so, unless you want to de-implement PartialEq for fn ptrs so that they can also not be compared any more when they occur as part of a larger type.

[oli-obk]

I was thinking about this because afaik there isn't a way parameterize over behavior without using a trait or relying on type inference, so I think there's no way to do the following:

Well... we do have opaque types, so you can use impl trait (or type alias impl trait in the future) to get that to work. For const generics I would imagine that once we have generic const generics that we could use function types instead of function pointers.

If it is enough for compile-time to be deterministic on pointer equality, then we can add function pointers to valtrees by encoding the Instance directly in the valtree similarly to how we follow references in valtrees and encode whatever they point at directly.

[varkor]

I agree that we want to be relying on existing abstractions (that potentially need to be extended to work with const generics) rather than direct pointer comparison.

[RalfJung]

valtree is not an existing abstraction, it is designed specifically for the needs of const generics.

If it is enough for compile-time to be deterministic on pointer equality, then we can add function pointers to valtrees by encoding the Instance directly in the valtree similarly to how we follow references in valtrees and encode whatever they point at directly.

I agree, that's how one would integrate fn ptrs into the valtree if we wanted to do that. But this is in conflict with the plan for patterns that I sketched here.

[varkor]

valtree is not an existing abstraction, it is designed specifically for the needs of const generics.

Sorry, I meant that we should be using opaque types. I don't think we should permit direct function pointer comparison (with valtrees or otherwise).

[RalfJung]

I'm not sure what you mean by "using opaque types".

EDIT: Oh, you are referring to @oli-obk's proposed alternative for the problematic code example by @lcnr, I see. I don't actually know concretely what they meant by that either, but as long as it's not involving any compiler changes that's fine. ;)

[oli-obk]

what I meant was to have fn foo<G: Fn(), const F: G>() that you can then call with foo<_, bar>(). This will not create a function pointer, but instead create a zst for the bar function. This does require a change beyond the independently desired generic const parameters. It could then potentially be made easier to use via impl Trait: fn foo<const F: impl Fn()>(), but again, nothing that makes us uncomfortable due to weird pointers.

So... I think we should just close this issue as wontfix as the gain is fairly small and there'll be an easy workaround

[RalfJung]

"easy workaround"? Not sure I agree.^^ Const-generic of generic type seem really tricky to me. In particular, don't we need a bound to ensure that type G actually can be used as the type of a const-generic?

[varkor]

It's an "easy workaround" assuming that we have implemented const generics with generic types ;) But we want these for other reasons anyway, so it seems a fair bet to assume we'll support them eventually.

[lcnr]

I don't think so, unless you want to de-implement PartialEq for fn ptrs so that they can also not be compared any more when they occur as part of a larger type.

deriving PartialEq for structs containing a function pointer would also trigger that lint ^^
so unless people explicitly silence/ignore it they would always get notified that this won't work as expected.

what I meant was to have fn foo<G: Fn(), const F: G>() that you can then call with foo<_, bar>(). This will not create a function pointer, but instead create a zst for the bar function. This does require a change beyond the independently desired generic const parameters.

so that's an interesting issue. foo<_, bar>() requires us to infer the type of G from F. This would mean that we have to typeck the const arg (bar) together with the containing body. Doing so is really hard, especially as all of this could be inside of a binder, e.g. let x: for<'a> fn(Struct<_, bar>), which afaik prevents us to typecheck these two bodies together.

This approach also prevents us from "just" using that type in a function signature because we don't allow _ there.

I do not think we're ever going to get foo::<_, bar>() to work, even with generic const param types we would still require an impl Trait declaration.

[oli-obk]

A less roundabout alternative may be to allow naming function zsts in type expressions and thus making

fn foo<T: FnOnce()>() {}

fn bar() {}

fn main() {
    foo::<bar>();
}

work. That would avoid all concerns around const generics, as they aren't involved at all.

It already works to specify

fn foo<T: FnOnce()>(t: T) {
    t();
}

fn bar() {}

fn main() {
    foo(bar);
}

so afaict this is solely a parsing/lowering issue (adding functions to the type namespace instead of just the value namespace). Though I don't know if there are any weird interactions around adding functions to the type namespace.

[lcnr]

Though I don't know if there are any weird interactions around adding functions to the type namespace.

I fear that doing so might not be possible because of backcompat. It also opens a new can of worms as we may now be able to implement traits for function objects or something 🤔 We can probably still forbid that though