Feature suggestion: Add static equals methods to Float and Double

[Hans Boehm]

What's the motivation for making it easier to spell a comparison method
that tells me that -1.0*0.0 is not equal to 1.0*0.0? I would have thought
that making this somewhat hard to write is a feature?

I agree that there are cases in which this method is useful. But they all
seem esoteric enough to me that it's not unreasonable for users to have
enough expertise to write the method. Or at least the method should have a
name that makes the unusual behavior explicit.

On Sun, Jan 6, 2019 at 2:58 AM Zheka Kozlov <orionllmain at gmail.com> wrote:

> Why don't we just add a generic method which compares any instances of
> Comparable?
>
> public interface Comparator<T> {
>         ...
>
> public static <T extends Comparable<? super T>> boolean equal(T x, T y) {
> return x.compareTo(y) == 0;
> }
> }
>
> Usage:
>
> Comparator.equal(1, 1); // true
> Comparator.equal(1.0, 1.0); // true
> Comparator.equal(2.0f, 2.0f); // true
> Comparator.equal("abc", "def"); // false
> Comparator.equal("abc", 1); // compilation error
>
> сб, 5 янв. 2019 г. в 09:33, <
> some-java-user-99206970363698485155 at vodafonemail.de>:
>
> > Hello Remi,
> > You are right, the proposed method names would prevent backwards
> > compatibility, I forgot to think
> > about that. Sorry for the trouble.
> > Maybe a different, currently not used name, such as `areEqual`,
> > `primitiveEquals` or similar would
> > be better.
> > What do You think about the addition of such a method?
> >
> > Kind regards
> >
> > > Remi Forax <forax at univ-mlv.fr> hat am 5. Januar 2019 um 00:50
> > geschrieben:
> > >
> > >
> > > Hi,
> > > it's not obvious to me that this is a source backward compatible
> change.
> > >
> > > if you have something like:
> > >   interface Fun { boolean eq(Double a, double b); }
> > >   ...
> > >   Fun fun = Double::equals;
> > >
> > > it's not clear to me which variant will be selected ?
> > >
> > > regards,
> > > Rémi
> >
>