The current depth limit is 300 calls within type inference (ConstraintSolver), I will check how it behaved before net9 and how much more would be needed to make this code compile in net9. There have been changes in the code for ConstraintSolver which can in turn lead to more recursive invocations of type solving.

@gusty:

I found out there was an infinite loop in type inference (= limit increase would not help) when the following was encountered:
static member inline ToSeq (_: 'T when 'T: null and 'T: struct, _: ToSeq) = ()

Is there a reason for this annotation I am not seeing?
I have made a fix that avoids the infinity recursion, but I would not want to also raise a new error when these two constraints are defined together.

Or is this somewhat intentional when writing SRTP members like this, to define a member which can be never satisfied by any type?

@T-Gro thanks for having a look at this

Or is this somewhat intentional when writing SRTP members like this, to define a member which can be never satisfied by any type?

Yes, in many cases we need to generate ambiguity in order to avoid overload resolution to resolve earlier. For those cases we have what I call "the impossible overload", which generates the ambiguity needed and at the same time provides no danger of resolving to it.

I found out there was an infinite loop in type inference (= limit increase would not help) when the following was encountered:

I suspected about an infinite loop, but of course, this worked since F# 2.0

Yes, in many cases we need to generate ambiguity in order to avoid overload resolution to resolve earlier. For those cases we have what I call "the impossible overload", which generates the ambiguity needed and at the same time provides no danger of resolving to it.

I do have code prepared which both fixes the recursion but also gives a new error for the struct and null combination of type parameter constraints. I believe this consistency check was only forgotten when the null constraint was added.

I wonder if there is another solution that would support the SRTP use cases and yet error in regular code to prevent invalid combinations.

(In the worst case, if no other solution is found to add this ambiguity, I can comment out the added consistency check for now...)

(In the worst case, if no other solution is found to add this ambiguity, I can comment out the added consistency check for now...)

Yes, if you introduce an error at this stage (v9 of the compiler) it would break lot of existing code.
But what about introducing a warning instead?

As for other inconsistency checks for type parameters goes, this one would inconsistent in being a warning and not an error.
But given it was used for a common SRTP technique, it could be justified. That way, you can ignore that specific warning code only.

I will make the change.