fn's can be used as const generics

[DutchGhost]

The following code fails to compile, because using function pointers as const generics is forbidden:

#![feature(const_generics)]

struct A<const F: fn()>;

However, if the function pointer is inside an array, it suddenly compiles:

#![feature(const_generics)]

struct B<const F: [fn(); 1]>;

Is this intentional, or should it also be forbidden?

[RalfJung]

The first is definitely intentional. fn() have an unstable notion of equality, in particular if they point to instances of generic functions: two entirely independent functions might have "equal" function pointers if they happen to compile to the same assembly code, and two identical instances of the same generic function in different crates (or even just different codegen units) might compare "inequal".

[RalfJung]

The second is a bug, good catch! I misread the issue description at first. This should not work in arrays -- I assume this would be fixed by properly moving to valtrees.
Cc @rust-lang/wg-const-eval

[lcnr]

#![feature(adt_const_params)]

struct B<const F: [fn(); 1]>;

still compiles, the issue is that function pointers are currently considered to be structural match. I intend to work on structural equality in the near (not that near) future, going to assign this to myself.

@rustbot claim

[DutchGhost]

Same issue with raw pointers (both *const _ and *mut _):

#![feature(adt_const_params)]

struct Works<const F: [*mut (); 1]>; // Should not work

struct DoesNotWork<const F: *mut ()>;

[RalfJung]

This no longer works:

#![feature(adt_const_params)]

struct Works<const F: [*mut (); 1]>; // Should not work

Looks like the issue got fixed? We should make sure we have a test though.

[lcnr]

this happens as const generics now relies on ConsParamTy instead of simply using structural match.