search for: does_not_return

...C++ class hierarchy with extra variants which are unnecessary > in the closed model. It looks like you might be right, and open variants might not be able to handle the pseudo-shared functions like llvm::CallInst::doesNotReturn and llvm::InvokeInst::doesNotReturn. We can't do the naive val does_not_return : [> `CallInst | `InvokeInst] t -> bool Like we can with closed variants: val does_not_return : [< llcallinst | llinvokeinst] t -> bool. Although... what if we just add another variant? This would work: type llcallinst = [ llinstruction | `CallInst | `CallSite ] type llinvokeinst =...

Erick, After some experimentation, I'd prefer the closed system. LLVM has some type peculiarities like the commonality between CallInst and InvokeInst. I find that the closed type system lets me express such constraints more naturally. Expressing these constraints explicitly in the open system involves annotating the C++ class hierarchy with extra variants which are unnecessary in