Generic parameter inference fails in the presence of arithmetic operations within generic interfaces

[saipraveenb25]

Minimal reproducer:

interface IModule<T, int N, int M>
{
    T eval(T x);
}

float foo<
    int N,
    Decoder : IModule<half, N + 6, 3>>
    (Decoder decoder, no_diff float3 wi )
{
    return wi.x;
}

void bar<
    int N,
    Encoder : IModule<half, 3, N>,
    Decoder : IModule<half, N + 6, 3>>
    (Encoder encoder, Decoder decoder, no_diff float3 wi)
{
    foo(decoder, wi);
}

Workaround is to be explicit about generic arguments, by invoking foo<N, Decoder> instead of just foo.

[csyonghe]

I worried that supporting this is the beginning to set foot in a scarry territory of trying to solve complex symbolic linear systems in the Slang type system. I would like us to avoid having to deal with this complex can of worms if possible.

[ccummingsNV]

This came through as a potential issue with SlangPy as well, which turned out to be due to the underlying resolution problem. I've added a test for it to the SlangPy function resolution that runs with/without the work around (and is currently disabled for the without case): https://github.com/shader-slang/slangpy/blob/main/slangpy/tests/test_generics.py

Once the issue's resolved (either with a confirmed fix, or a confirmed won't-fix) I'll update the test accordingly.

[saipraveenb25]

@csyonghe: I agree, it feels like things like inferring N from N + 6 is simple enough, but it does get quickly harder when we start seeing constraints like N + M + 5 etc..

I was hoping we could do exact structural matches: N + 6 can match with M + 6 and is effectively an equality constraint (N == M).
Alternatively, we could provide a better error like "Cannot infer parameter "N" from constraints, use explicitly specialization with <...> ".
Another approach is to allow partially-specialized generics like foo<N>(decoder) where "Decoder" can be pulled from "decoder" but "N" is set explicitly.

[saipraveenb25]

Another comment is that these errors occur even if there is an additional equality constraint for N that can be used for inference instead.

E.g.: in

void bar<
    int N,
    Encoder : IModule<half, 3, N>,
    Decoder : IModule<half, N + 6, 3>>
    (Encoder encoder, Decoder decoder, no_diff float3 wi)
{
    foo(decoder, wi);
}

I think it's fine to not use N+6 for inference, but Encoder does have an N, so we can use that to infer N. Right now, I believe this doesn't work.