Comment author: @gasche

That could be a good idea, but please note that we do not have the static knowledge to do that reliably at compile-time:

• you may use generic comparisons in polymorphic functions that are later instantiated with abstract types (eg. you may use List.assoc on an abstract type, and without a cross-module analysis you can't guess that List.assoc is tainted with that ugly generic equality)

• the generic comparison operators are defined in the standard library through "external ( = ) : ..." definitions, and the compiler can check that a given identifier was added by the environment by such an external. But you may rebind it and the check will fail: (let (=) = (=);;) would probably be enough to defeat the "simple way" to tell if you're looking at a generic comparisons; in the real world this may happen when you parametrize functions over the comparison operation, or functors parametrized over OrderedType that happen to be instantiated with Pervasives.compare

Do you still see value in a static warning with those rather damning limitations? Are you rather looking for a way to instrument your code to detect use of generic comparisons at runtime?

Comment author: @ppedrot

In a ideal world, we would use typeclasses, but here, even a overly cautious warning may be informative enough. Indeed, it should also complain when used polymorphically, so that the very definition of List.assoc would raise the warning. This is already better than nothing.

The second point is more problematic; a very involved way to fix it would be having not-so-polymorphic quantifications in the type-checker, but I imagine this is far out of reach.

Comment author: @gasche

This is what SML does with "equality types" double-quoted type variables: ''a. This is a convoluted way to have a very specific qualified type (Eq a) => ... indeed. Waiting for type classes in OCaml!

Another solution some people have used is to compile their code in an environment where (=), (<) and all are rebound to () or 1, so that the compiler forbids them from using it altogether.

I don't think your idea of warning on polymorphic uses is reasonable enough (from a convenience point of view) to actually get implemented by someone. The runtime instrumentation thing, however, may be doable; you can already somehow emulate this on client side by intentionally wrapping the representations of your abstract types in a closure or an object.

Comment author: @alainfrisch

or an object.

Objects can be compared/hashed with the generic functions (using their internal ids).

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

See also #1642

and #6338

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

x-ref #9926

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.