Just as info: with .NET 8 alot of throw-helpers come inbox (ArgumentOutOfRange, ObjectDisposed, etc.).
So I think it's good to have same signatures in the ThrowHelper here, so that an update later is easy for the call-sites.

Maybe we should already add the net8.0 TFM and make this a shim.

I'm marking the PR as ready for review. There are going to be multiple parts to make it easire to review.

Adding .NET 8 TFM and referencing inbox throw-helpers should probably be done in a separate pr.

One interesting thing I've encountered while working on this PR is that jit generates a lot of code for string interpolation even if the argument is a constant (though nameof works fine).

One interesting thing I've encountered while working on this PR is that jit generates a lot of code for string interpolation even if the argument is a constant (though nameof works fine).

Interesting... The nameof case shows that it does the right thing for at least some constants, but for fails with ushort.MaxValue... Maybe because it's a non-string and so requires a conversion, and Roslyn doesn't do that?

I'd flag this on https://github.com/dotnet/roslyn (assuming there's not already an issue)

Aside from that there are some test failures...

Aside from that there are some test failures...

Some issue with downloading PG, gonna restart...

it's a non-string and so requires a conversion, and Roslyn doesn't do that?

For codegen look at what Roslyn generated.
Right now $"ABC{ushort.MaxValue}" is an interpolated string, and not evaluated at compile-time. Thus lots of code.
C# / Roslyn wise I think dotnet/csharplang#2379 is the issue tracking this (there are soo many over there...).

For strings in interpolation holes C# 10 has the feature of "constant interpolated strings".
So all other types are normal interpolated strings, with runtime evaluation.

For codegen look at what Roslyn generated.
Right now $"ABC{ushort.MaxValue}" is an interpolated string, and not evaluated at compile-time. Thus lots of code.
C# / Roslyn wise I think dotnet/csharplang#2379 is the issue tracking this (there are soo many over there...).

For strings in interpolation holes C# 10 has the feature of "constant interpolated strings".
So all other types are normal interpolated strings, with runtime evaluation.

It seems like integers (and I guess that includes uint) aren't a constant interpolated string because of a formatting differences across cultures?

dotnet/csharplang#2951 (comment)

It seems like integers (and I guess that includes uint) aren't a constant interpolated string because of a formatting differences across cultures?

Ah yeah, that makes sense. Though if memory serves, there's a way to specify invariant culture inside the interpolation, and that could be done at compile-time.

Am fine with this, though I wonder if it's worth systematically doing this for the entire codebase... In other words, there are methods which are never going to get inlined anyway (because they're big), and so doing this there doesn't seem to have much value; in some places it also makes code readability worse (because we can't throw from expression context).

Yeah, I'm definitely not going to remove them from everywhere any time soon)
Probably just concentrate on the "open_connection->execute_query->close_connection" path for now (I think the good idea will be to get rid of string interpolation).
The point here isn't only about inlining, but to also make the generated code smaller (this can allow jit to use less registers and operations, string interpolation is prime example of that).