[WIP] Improve type inference for non-sealed types

[gusty]

This attempts to solve a longstanding problem where type inference in presence of member constraints is broken, but succeed for sealed types.

A repro will be added as a test.

[dsyme]

A repro will be added as a test.

Just to mention we'll need much more systematic testing to accept a change in this area.

There's a lot of additional testing in #6805 which will be relevant, but I think you should incorporate bespoke systematic testing across several dimensions of variability.

[gusty]

Thanks @dsyme I agree that this would require lot of testing.
Still, I think this is something we need to fix somehow, specially considering the desire to improve SRTP support.

The code I'm testing is from this issue #4171 I just revived with a new repro. Right now, with the code I have so far it compiles fine.

But at the moment this is just a playground to allow me to understand better what's happening and why a non-sealed type makes things bad when we have a backtracking mechanism in place.

Btw, it's kind of funny that the only test this PR breaks at the moment is also my code, so I'm still breaking myself. But talking seriously, this is also an indication that including F#+ tests here would be a good thing, it's a shame this idea was pushed back (CC @cartermp )

[TIHan]

I'm not sure what the change is doing at the moment, but to comment my thoughts on SRTP changes:

We should be trying to fix flaws in SRTP first before adding more improvements/additions to it. I feel this way because I think that adding more improvements/additions could add even more flaws in SRTP which will not be brought up until years later. I've looked at SRTP issues a few weeks ago and my head was exploding due to how complex it was. Opening it up even more causes me to worry.

I don't know if this change will fall into the "fixing flaw" or "improvement/addition" category because I need to see an example to understand it.

[gusty]

@TIHan I agree with you, except that to me this is clearly a flaw, maybe I should change the title to reflect this.

Also, this is something we definitely have to fix as part of the first item in this list: fsharp/fslang-suggestions#243 (comment)

As you say, this is really hard to understand, but I'm doing the effort because I want to see these issues solved for once.

[wallymathieu]

This is clearly a flaw as @gusty mentions. It would be nice to have a bit more consistency.

[KevinRansom]

@gusty , is this PR still in development? it's been 9 months since the last commit or comment. I am closing this for now, please re-open when you are ready to proceed with it.

Thanks

Kevin

[gusty]

I might do more work in the future.
If so, in principle I'll be interested only in the checks, then only if I ever get something working I would be interested in merging it.
Thanks !