On Feb 23, 2019, at 3:25 AM, Remi Forax <fo...@univ-mlv.fr> wrote: > > This remember me another issue, we are discussing a lot about Java the > language but that's not the only language that run on the JVM, by making acmp > be an equivalent of substituableEquals() we are making a choice of semantics > that may be ok for Java the language but clearly this change of semantics > also impact the other languages, i'm thinking about Clojure's identical? by > example.
JVM languages can and will change their translation strategy if they don't like what acmp does (regardless of what we end up doing). That's one reason it seems likely to me that the losers of the acmp sweepstakes (including my old favorite, the one that is allowed to return false if the JVM wants to punt), should be given useful jobs under other names, not "acmp". My working title for the punting acmp is System.fastSubstitutabilityCheck. The reason acmp is hard is that it's running in old code that hasn't yet be upgraded. Also, we want upgrading to be easy. This is one reason today's generics (though not reified) place constraints on tomorrow's reified generics. So it's not quite correct to say "that code isn't written yet" as if it could compile under whatever new rules we want.
