Could function pointers with anyopaque parameter accept functions with opaque pointer?

Brainstorming
1

Since *Opaque automatically coerces to *anyopaque on assignment, it feels like *const fn (*Opaque) void should also automatically coerce to *const fn (context: *anyopaque) void

const Opaque = opaque {};
fn testFn() void {
    const impl: *Opaque = undefined;
    // opaque ptr is trivially assignable to anyopaque ptr
    const opaq: *anyopaque = impl;
    _ = opaq;

    const implFn: *const fn (context: *Opaque) void = undefined;
    // error: expected type '*const fn (*anyopaque) void', found '*const fn (*Opaque) void'
    const vtableFn: *const fn (context: *anyopaque) void = implFn;
    _ = vtableFn;
}

I feel like this would be such a good QoL without any tradeoffs when dealing with vtables. Is there some reason why this coercion should not be done automatically? Maybe too complex on the compiler side?

2

I’m not sure this should be brought in, the argument is basically that because it’s implicit conversion as a pointer, it should be coerced also when its a function parameter, but then why not just allow arbitrary pointer conversions? I am much more likely to have a VTable pointers with the actual straight type like *const fn (self: *Self) void, and saving the overhead of one very specific @ptrCast is not useful enough to add language rules in my opinion.

A more general rule where any pointer parameter could be implicitly cast to an anyopaque pointer (would save on the @ptrCast in all the other cases as well) could be cool.

3

What you are saying makes sense so that I was wondering why I didn’t think of that, but you can’t cast anyopaque to non-opaque as trivially as to opaque due to alignment issues. Wnich is why you will often also see @alignCast in the vtable implementations. So I can see why zig devs wouldn’t want to do that implicitly. Afaik anyopaque and opaque will always have the same alignment (of 1), so I see no issue there.