strongly love this. just need a story told through the code to explain what's going on plz. thanks!

@CyrusNajmabadi Ready for review.

@CyrusNajmabadi I think I've addressed all your feedback. PTAL.

On vacation now. Will do so next week!

A couple of things are intentionally left out for a follow-up:

• Support || as the entry point
  • e.p == 1 || e.p == 2 => e is { p: 1 or 2 }
  • e is not C c || !c.p => e is not C { p: false }
• Remove unused variables after applying the fix
  • case C v when v.p => case C { p: true }
• Cover more pattern combinations before falling back to and
  • Should also include simplifying the resulting pattern

I think the last two should be done as a reducer to be applied for any simplification run.

tagging @CyrusNajmabadi for review.

So my general feedback follows some thigns i've mentione din the past. Namely that the code ends up reading far too cryptically and too cutely. i feel like there's an overemphasis on trying to express thigns in the most compact pattern+tree-tranform form as possible. And i feel like that works because in your head you have a model of the exact tree forms and what you're extracting/combining/reforming. However, it makes the code feel far too dense and unclear as to waht's going on. I'd far prefer a simpler step-by-step recipe-like form where we state what we're looking for, and what we have extracted out, and what we are transforming into.

THis is esp. critical to me as it's very hard to otherwise know what's going on, which is important so that reviewer can gauge what might have been missed or what might need work.

@alrz what do you think your next steps will be here?

So my general feedback follows some thigns i've mentione din the past. Namely that the code ends up reading far too cryptically and too cutely. i feel like there's an overemphasis on trying to express thigns in the most compact pattern+tree-tranform form as possible. And i feel like that works because in your head you have a model of the exact tree forms and what you're extracting/combining/reforming. However, it makes the code feel far too dense and unclear as to waht's going on. I'd far prefer a simpler step-by-step recipe-like form where we state what we're looking for, and what we have extracted out, and what we are transforming into.

I'm not sure exactly what is the request here. I did actually write this in "step-by-step recipe-like form" with a few refactoring to reuse code whenever possible. I have no idea what could be cryptic about that.

I have no idea what could be cryptic about that.

I think part of it is the returning of lambdas that then do the work later. so it's a bit unclear how to distinguish the matching portion from the transform portion. this is not a complaint. it's more an observation that this feels very different from how we generally have shipped refactorigns in the past.

I did actually write this in "step-by-step recipe-like form

Yes. but not always. For example, if i see:

            if (TryGetCommonReceiver(leftReceiver, rightReceiver, model) is var (commonReceiver, leftNames, rightNames))
            {
                return root =>
                {
                    var leftSubpattern = CreateSubpattern(leftNames, CreatePattern(leftReceiver, leftTarget, leftFlipped));
                    var rightSubpattern = CreateSubpattern(rightNames, CreatePattern(rightReceiver, rightTarget, rightFlipped));

It would be nice to have a general example of what's going on there.

--

That said, i think this is fine and i'm going to merge it in :) There were a couple of pieces of feedback not responded to. However, we can see based on if users run into issues with that if we need to do anything here.

Thanks much for the awesome contribution :)