Is there a possibility of the string equality operator (==) being fixed?

[Pedro Lamarão]

Also, this behaviour that may seem weird from programmers coming from C# is
quite familiar to those coming from C++.

int i1 = 1;
int i2 = 1;
int* p1 = &i1;
int* p2 = &i2;
std::cout << (i1 == i2) << std::endl; // prints true
std::cout << (p1 == p2) << std::endl; // prints false

Atte.
Pedro.

Em ter., 31 de out. de 2023 às 04:34, Jens Lideström <jens at lidestrom.se>
escreveu:

> Remember that C# has its own quirks regarding the behaviour of ==.
>
> Example of the behaviour in C#:
>
> ```
> string s1 = new String("1");
> string s2 = new String("1");
> object o1 = s1;
> object o2 = s2;
> Console.WriteLine(s1 == s2); // True, overload for string kicks in
> Console.WriteLine(o1 == o2); // False, reference equality!
>
> int? i1 = 1;
> int? i2 = 1;
> object o1 = i1;
> object o2 = i2;
> Console.WriteLine(i1 == i2); // True, overload for Nullable<int> kicks
> in
> Console.WriteLine(o1 == o2); // False, reference equality!
> ```
>
> That is, in C# the behaviour of == varies for the same objects,
> depending on what types the references have.
>
> Both approaches have their advantages and disadvantages. But to me
> Java's approach seems more sensible: For reference types == always means
> reference equality.
>
> Best regards,
> Jens Lideström
>
> On 2023-10-31 03:10, tzengshinfu wrote:
>
> > Thank you, Anatoly, for informing me about `IntegerCache`.
> > As a developer experienced in C# and JavaScript/TypeScript, I am
> > currently responsible for migrating our in-house systems from C# to
> > Java.
> > I also have the responsibility of training and sharing knowledge with
> > others.
> >
> > I was surprised by the following result in Java:
> >
> > ```java
> > Integer int1 = 100;
> > Integer int2 = 100;
> > Integer int3 = int1 + 100;
> > Integer int4 = int2 + 100;
> > out.println(int3 == int4); // false
> > ```
> >
> > This is different from how it works in C#:
> >
> > ```C#
> > Int32 int1 = 100;
> > Int32 int2 = 100;
> > Int32 int3 = int1 + 100;
> > Int32 int4 = int2 + 100;
> > Console.Write(int3 == int4); // True
> > ```
> >
> > Now, I understand that Java's design philosophy (thanks to Brian for
> > patiently explaining) leads to this behavior.
> > I will make an effort to understand how this works under the hood and
> > include it in my Java FAQ documentation.
> > My initial thoughts and suggestions were aimed at colleagues who are
> > also transitioning from other programming languages and newcomers to
> > Java who bring their language experiences.
> > Naturally, they might find the unexpected results in certain use cases,
> > and I hope to find ways to make this learning curve smoother without
> > disrupting the existing framework.
> >
> > Without breaking the current architecture, both Solution A (changing
> > String1 == String2 to String::equals()) and Solution B (introducing a
> > new string/str class to replace the String class) are unfeasible
> > (thanks to Nathan for preventing "I think it's rarely used, but in
> > reality, it's not, and everything breaks").
> >
> > Can I propose a Solution C?
> >
> > Solution C: Introduce the === and !== operators for value comparison
> > (equivalent to Object::equals()).
> >
> > For example:
> >
> > ```java
> > if (Integer4 === Integer1 + Integer2 + Integer3) {
> > // Do something...
> > }
> > ```
> >
> > Would be equivalent to:
> >
> > ```java
> > if (Integer4.equals(Integer1 + Integer2 + Integer3)) {
> > // Do something...
> > }
> > ```
> >
> > From a visual perspective, I believe that the === and !== operators can
> > reduce the chances of typos and make the code look cleaner, with fewer
> > parentheses compared to using equals().
> > Sometimes, symbols can convey meaning more clearly than text. This idea
> > stems from my experience with Delphi, where the use of keywords like
> > begin and end mixed with variable declarations and expressions made
> > code difficult to read in a plain text editor, despite IDE features
> > like highlighting and automatic formatting. Java's use of {} solved
> > this issue.
> > However, there are also counterexamples, such as Rust's code, where
> > excessive symbols may contribute to a steep learning curve.
> >
> > /* GET BETTER EVERY DAY */
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231031/eb5d2908/attachment.htm>