True? :0

== doing a slow string compare is stupid. Even in Rust I refuse to use the equality operator for strings and instead explicitely call eq()

@12bitfloat Check your information better.

Here, C# for example

https://referencesource.microsoft.com/...

@highlight
public static bool operator == (String a, String b) {
return String.Equals(a, b);
}

@NoToJavaScript So? That's what I said. As someone saying they don't like JavaScript I'm pretty dissappointed in you that you don't see a string compare as slow

@12bitfloat There is no difference between == and eq() in Rust.. as far as I know. What do you mean with slow string compare?

@simulate There isn't but I don't like == for string compare so I'm using eq(). Just an idiomatic thing

@12bitfloat Rust does operator overloading, std::cmp::Eq can be implemented for any type, and == is just syntactical sugar for eq().

Y'all should shut up though, you don't know pain until you've worked with PHP.

=== null? is_null? isset? empty? null == false? null == 0? null == []? null == ""? null["pear"] === null["apple"]?

@12bitfloat So you'd rather use a less-standard comparison function than the nearly universal == operator even though they do the same thing? Hm.

I think @12bitfloat’s point has been missed a little. It’s a valid idiomatic point. I personally prefer == but whatever floats your boat.

I think calling it a slow string compare isn’t really fair though. It’s not like you’re sorting / searching an array. String comparison even with large strings is quite fast.

@FelisPhasma

I don't think it has anything to do with performance. == in Java for non-interned strings, even if equal, will return false as it compares memory references, where String.equals understands that a dereference is necessary.

It's also why I dislike Java -- for a language which pretends to make devs not worry about memory, it makes devs worry about memory very often. And what's worse, it makes you worry about memory in vague inconsistent ways, you're still thinking about heap vs stack values because of implicit differences in types.

Rust might be a bit steeper of a learning curve, but at least it just explicitly smacks you in the face with the difference between &'static str and String.

Maybe that's just preference though.

Well, String literals such as "abc" are saved in memory as a String object. When more than one String literal has the same content, then they are only stored once in memory, leading to the following:

String str1 = "A"; // String object with content "A"
String str2 = "A"; // String object with content "A"
System.out.println(str1 == str2); // true because only saved once in memory
Though: "A" == new String("A") // false, different objects
And of course "A" != "B" because they are two different objects.

I think the confusion exists because people think String literals are primitives.
Is this a problem to the compiler? I don't think so - it's just doing what it's asked to do. After all, it's not a person but a process of in - alg - out. It's more like: senior programmer is annoyed by misunderstanding of String objects by the novice programmer.

@AlgoRythm Yes, probably because I'm used to Java and partly because I hate operators doing expensive work (Yes a string compare is expensive compared to a reference compare)

@bittersweet That's what I said. == is just a call to eq(). I still don't like == for string compare

@12bitfloat In all respect, and I understand that you are used to this from Java, but the great thing about Rust is exactly that you have dedicated reference types. So when you know your types, which you should, you know the semantics of the operator, and can tell when == is expensive and when it isn't.

@simulate True and I will probably switch to using it sooner than later but for whatever reason I still have this bad gut reaction to operator overloading

@12bitfloat Operator overloading seems like a bad term for this.. because the operators don't really have a default behaviour other than calling eq() from the PartialEq trait. Any type implementing PartialEq can be compared using ==, and all it does is call the given implementation of PartialEq::eq(). So you are not overwriting any default behaviour. You just define what the == does for a given type (or two different types).

@12bitfloat Whatever you're used to. And it's not very useful to do a reference equality comparison on strings.... I can't think of many uses to see if one string is *literally* the same thing as another. Usually I do string comparison to see if they are equivalent.

@simulate Which effectively is operator overloading

@12bitfloat Hm maybe you're right