error FS0073: internal error: Undefined or unsolved type variable: ^_?82069

[gusty]

I'm creating this issue to track all occurrences of this error for which there is already a fix in the feature/ext branch.

This error is a longstanding one and it's still being reported from time to time with many different repros.

I'm personally tired of wasting my time finding ways to workaround it, which is unfortunately not always possible.

I think the main commit that fixes this issue is here: f57f947

And as far as I can tell is totally independent of RFC-1043, the only reason why it was fixed there is because F#+ was used to test the new feature and F#+ finds very frequently that error.

Here's a list of existing reported issues of this error, which I can confirm they work when running them from feature/ext even without the language preview switch which would activate RFC-1043.

• FS0073: internal error: Undefined or unsolved type variable when using records with generic type variables and overloaded operators in inline function #9416

• Stress test on type system involving many statically resolved type parameters #9382

• Compilation fails depending on runtime path (???) #7384

• error FS0073: internal error: Undefined or unsolved type variable: ^_?82069 fsprojects/FSharpPlus#331

I can't stress how important is to get this bug fixed in the constraint solver area, and AFAIK bugs have priority over features, so I think efforts should be invested in order to get the existing fix merged into master.

[cartermp]

Tagging #3508 and #9717

[dsyme]

I've linked this in #6805 to investigate this in the context of that branch work

[dsyme]

Regarding priority - please note that FSharpPlus is using a combination of techniques (SRTP, overloading of witnesses, chained-generation of new SRTP constraints during solving, subtyping etc.) that are not appropriate for an F# library without a considerable future overhaul of F# SRTP. Its goals should likely be greatly simplified to work on a simpler technical basis and anywhere this bug is being hit is likely a prime candidate for simplification. The guidance for F# 1.0-5.0 would be "Don't make or use F# libraries that regularly hit this problem"

That said, when I or others return to feature/ext we can look to see if the fix can be separated from the branch work. My estimate before was that it was better not to do this due to the need to put any changes in this area through a very long "preview" cycle.

Given previous instability caused by adhoc acceptance of changes, I basically regard any changes in the SRTP area as language feature work requiring significant bake time and /langversion:preview

[gusty]

@dsyme I agree in that F#+ has some modules which heavy use SRTPs taking it to a point which was not considered when they were initially designed, as they were mainly intended to address generic arithmetic problems.

But if you go through these bugs, you'll find many different levels of complexity, and they are not just F#+ specific.

Namely, if you have a look at the first one in the list, you'll see that it's a very simple code and guess what, it's just math stuff, no fancy category theory thing.

My feeling is that, if there are no more issues reported is because it is good enough to scare people.