This function seems too ad hoc: it is used in a single case (in Matching.complete_pat_constrs), where it is nearly immediately refined into checking than rather than a Simple.pattern we have a [ `Constr _ ] pattern_data.

I disagree with the general argument:

• assert_<static-knowledge> functions are not ad-hoc, there are general ways to add a dynamic check at the boundary of a statically-checked region of code. In particular they are useful to gradually introduce static knowledge in a codebase that relied on unspoken invariants and dynamic checks.
• The fact that a function is used only once is not in itself a bad thing. (It is a mistake to believe that functions should only be defined to factorize multiple occurrences of a pattern.) If a function makes sense as a unit of abstraction, it has value even if used only once.

(Of course the reason why we have assert_simple is that we used it for other things as well in previous iterations of the patchset, and I kept it around as a general solution to the problem of coercing patterns into their simple form.)

This being said, I agree that, in this specific case, there is an independent improvement that we could make, which is to carry around a finer-grained argument of type constructor_description pattern_data. This would be very nice, and/but it is a non-local change, unrelated to the present PR, that would make more sense as a separate commit.

I changed the code according to your comment: I inlined the definition of assert_simple and got rid of it (the mega-patchset does not use it more for now, and we can always re-introduce it later if we want). I first inlined it in Parmatch.complete_constrs, to be closed to where the existing comment was, but this entailed weakening the Parmatch interface (to take a general pattern for this function). So I moved the inlining and the comment to the Matching side.

Note: I'm trying to push a constructor_description pattern_data in this part of the code, but it is proving quite difficult because this interacts with the compile_test machinery which is a bunch of unstructured polymorphic higher-order functions.

Here is a patchset that pushes a constructor_description pattern_data all the way to complete_constrs: trefis/ocaml@rematch-standalone-patterns...gasche:rematch-complete-constrs

(I propose to send it for review after the fate of the current PR is decided.)

The patch looks good, but it can indeed wait.

Of course my preference would send it sooner rather than later. But I don't see the point of piling up more open review work for you before this one is closed, and I don't think it would make sense to merge the two PRs (they are mostly orthogonal).