[nodra]

Is no generics with AOT the only catch?

[zigzag312]

Generics do work with AOT.

You can't generate new code at runtime (Reflection.Emit) with AOT.

[nodra]

My wording was incorrect. My apologies. I meant open generics (List<T>)

[neonsunset]

Why would generics not work with AOT?

[nodra]

I meant open generics. My wording was incomplete.

[neonsunset]

Why would open generics not work? If generics had any issues on NativeAOT it would have been an unusable target.

[nodra]

Last time I tried I had troubles. My understanding is open generics (like List<T>, without specifying T) don’t fully compile because Native AOT lacks a JIT to handle unspecified types at runtime. Closed generics work fine, though, as they’re fully known at compile time. Am I wrong in my thinking?

[neonsunset]

This does not line up with the implementation. You may want to ask in DotNetEvolution or dotnet/runtime discussions as there you can get a definitive answer why something didn't work - most of the time it is best to avoid such assumptions.

Open generics simply propagate type parameters down - T: class produce shared method bodies, as they do with the JIT with the type being passed implicitly. For T: struct the corresponding code is fully monomorphized. This is not related to JIT at all where the main distinction with NativeAOT is when compilation happens.

All generic scenarios are supported. Unbound un-analyzable reflection as well as anything that requires JIT like assembly loading or reflection emit - this doesn't work for obvious reasons.

[nodra]

Only generic scenarios that can be resolved and compiled at build time are supported in NativeAOT. So, the statement that “all generic scenarios are supported” is overly broad. I’ll try to avoid such assumptions :).