> On Oct 9, 2018, at 12:00 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > Aside, from the semantics point of view, this is a very bad example, > implementing Comparable means you have a natural order for the class and > taking a Comparator as parameter means there is no natural order.
Note that 'comp' has an initializer. I'm not "taking a Comparator as a parameter"—I'm building a comparator and cacheing it. (Probably should be "static final"...) We have a rich API for building Comparators. I would expect most non-legacy implementations of Comparable to implement their 'compareTo' method by delegating to a Comparator. And you don't want to build the Comparator each time the 'compareTo' method gets called, so you'll probably stash it in a field. I'm curious about what you'd expect someone to put inside their 'compareTo' method body, if not an invocation of Comparator.compare. (Of course they can roll their own int-fiddling logic, but why when the Comparator API is sitting right there?) > The main issue with the 'try both' strategy is that we already support two > kinds of method ref, static method and instance method, so if the compiler > also tests the two kind of strategy, it means that we have a 2x2 matrix of > possible signatures to match, this introduced too many possibilities for a > feature that is supposed to be readable for everyone. I'm sympathetic to the argument that more complexity is bad. On the other hand, this is an inference problem, and people tend to be pretty happy with complex inference rules, if those rules produce a result that is what they intuitively expect, and as long as reasonable ambiguities are reported as errors rather than arbitrarily resolved.
