string equality should be based on contents not identity

[jyasskin]

$ cat test.rs
fn main() {
  if("0" == "0") {
    log "equal";
  } else {
    log "not equal";
  }
}
$ ./rustboot -L . test.rs -o test.exe && ./test.exe
rt: 0xa0563720:0xbfffece4:0x00100200:     upcall log_str("not equal")

We can work around this in the library, but I'd rather not.

[graydon]

Flat vs. deep equality is something we've talked a bit about during the spring; I believe we settled on the notion that the operators would behave "machine-like" (such that == and < would do shallow, memcmp-like, pointer-comparing versions) and we'd add operators or library code to do deep compares.

Several related rationales here:

• That the other operators (+, -, !, etc.) are machine-like,
  constant-time, atomic.
• That deep structural comparison is really only "easy" to define in
  immutable (acyclic) cases, and having "==" only work on immutable
  values would "feel weird" to users.
• That compare-by-ref is more like what existing languages with
  explicit pointers do for such operators, on the pointer edges.
• That users will more-likely want to customize the deep version
  than the shallow version, so most APIs will support "pass a
  comparator function" anyway.
• That the default should be the fastest version.

I'm not sure all these are equally convincing, or at all so. It's a complex topic. Thoughts?

[jyasskin]

Above all, I want == to fail to compile in cases where it's going to be confusing. In Java, where == works on String, but you always want to use .equals instead, I tend to write bugs.

I think part of this is my confusion between logically boxed and unboxed types. I was looking at a str as a logically unboxed type, even if there's a pointer involved in its implementation. Similarly, objs, recs, tups, and vecs feel unboxed since I didn't write an @.

I don't think you can get equality right for all types without user (library author) input. You can for strs, and tups, recs, and vecs of primitive types, but any obj could have multiple representations of the same value. I'd leave it a compile error on objs if you don't want to let users overload it.

If == must be defined everywhere (for use in generic functions?), I'd expect it to compare boxed values as pointers, and unboxed values recursively down to primitive types or boxes. That ensures that it never falls into a cycle, without a mutability restriction. Unfortunately, that still conflicts with my first rule on user-defined types like hashtables, where it'll give the wrong answer.

I don't really buy that Rust should trade safety (expected results from ==) for speed (pointer comparisons).

[graydon]

Shifted to rustc.

[graydon]

This is done in rustc some time before abd78f2.