CompileFunctionPointer<T> and generics

[signal cedar]

The documentation mentions that "Also, avoid wrapping BurstCompiler.CompileFunctionPointer<T> within another open generic method." https://docs.unity3d.com/Packages/com.unity.burst@1.8/manual/csharp-function-pointers.html Would the following code be ok or is it also considered to be part of an open generic method? ```
public class MyClass<T>
{
public void Compile()
{
BurstCompiler.CompileFunctionPointer<Function>(SomeFunction.SomeFunction);
}
}

public class Inherited : MyClass<int>
{
    
}```

[red gulch]

I think that would work.. (But, I'm also confident with your ability that you can test this yourself fairly easily) 😉

[hoary geode]

I've had the same kind of doubts as the "avoid" phrasing suggests that some potential issues might not be as obvious as producing compile time or runtime error. Shall we expect an error everytime there is a potential generic issue with function pointers?

[signal cedar]

Yeah I'm asking for the same reason Marc mentions @red gulch 👀

[frail ermine]

The issue with generics is about being able to know the type at compile time, statically. When you close CompileFunctionPointer<T> with CompileFunctionPointer<Function> this to totally fine to call from within a generic type's method / generic method, as long as Function isn't actually a generic type (i.e. it's not a nested type inside of a generic outer type). If Function were generic, then it would need to be closed and in the example about it wouldn't be since Function is actually MyClass<T>.Function which Burst may not be able to resolve statically. It's those cases where you'll have problems

[signal cedar]

Thanks for the explanation kevin, would the following case be able to be resolved statically? ```public class MyClass<Function>
{
public void Compile()
{
BurstCompiler.CompileFunctionPointer<Function>(SomeStaticMethod);
}
}

public class Inherited : MyClass<FunctionType>
{
    delegate FunctionType();
}```

[frail ermine]

It can if MyClass<SomeConcreteType>.Compile() is written in code somewhere burst is scanning.

Your example changed the generic parameter from T to be Function. So your example needs some other code to specify the fully closed call to CompileFunctionPointer

[signal cedar]

Ok I see, thank you

[frail ermine]

No problemo.

This is how the RegisterGenericJob/ComponentType attributes work, since they make you write out the fully closed form which can be scanned for. We do handhold the process a bit to make things quicker but the idea is to make a fully closed type known statically