[delta_p_delta_x]

> when your program or one of its libraries relies on reflection

Fair enough; perhaps it'd be worthwhile to throw a compiler error if both reflection and trimming were attempted.

> Native AOT is good for startup time (FaaS), but tiered JIT will likely outperform it in long-running applications

This is intriguing; could you elaborate on the latter? Would tiered JIT perhaps have more runtime information which would be more useful when optimising frequently-accessed code paths or tight loops?

[MStrehovsky]

> Fair enough; perhaps it'd be worthwhile to throw a compiler error if both reflection and trimming were attempted.

The tooling already generates warnings for any spot in the program that uses reflection _in a way that cannot be statically analyzed_. Fixing code to make it work with trimming is equivalent to fixing warnings. Here are a couple case studies: https://devblogs.microsoft.com/dotnet/creating-aot-compatibl...

[orthoxerox]

> This is intriguing; could you elaborate on the latter? Would tiered JIT perhaps have more runtime information which would be more useful when optimising frequently-accessed code paths or tight loops?

Exactly. In addition to that, it's hard for the compiler to guess which branch is the frequent one in code. Or if it's the only one, if, for example, you link against implementations of some interface but only use one at runtime.

[soulbadguy]

> Fair enough; perhaps it'd be worthwhile to throw a compiler error if both reflection and trimming were attempted.

In language/platform with dynamic loading, it's hard for the compiler to "perfectly" predict which piece of code will ending up being executed at compile time. I think would result in a lot of false positives.