Join GitHub today
string equality should be based on contents not identity #123
We can work around this in the library, but I'd rather not.
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:
I'm not sure all these are equally convincing, or at all so. It's a complex topic. Thoughts?
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).
In particular: * The RFC associated with rust-lang#127 should have had a link to rust-lang#19 as well (and has been assigned RFC rust-lang#19); it also was revised to match the markdown href style of other RFCs. * RFC rust-lang#34 needed its header entries filled in, * RFC rust-lang#123 had a typo in its header, and * RC rust-lang#155 was revised to match the markdown href style of other RFCs.
* avx: _mm256_movedup_pd * avx: _mm256_lddqu_si256 * avx: _mm256_rcp_ps * avx: _mm256_rsqrt_ps * avx: _mm256_unpackhi_pd * avx: _mm256_unpackhi_ps * avx: _mm256_unpacklo_pd, _mm256_unpacklo_ps * avx: _mm256_testz_si256 * avx: _mm256_testc_si256 * avx: _mm256_testz_pd * avx: _mm256_testc_pd * avx: _mm256_testnzc_pd * avx: _mm_testz_pd * avx: _mm_testc_pd * avx: _mm_testnzc_pd * avx: _mm256_testz_ps, _mm256_testc_ps, _mm256_testnzc_ps * avx: _mm_testz_ps, _mm_testc_ps, _mm_testnzc_ps * avx: _mm256_movemask_pd, _mm256_movemask_ps * avx: _mm256_setzero_pd, _mm256_setzero_ps * avx: _mm256_setzero_si256 * avx: _mm256_set_pd, _mm256_set_ps * avx: _mm256_set_epi8 * avx: _mm256_set_epi16 * avx: _mm256_set_epi32 * avx: _mm256_set_epi64x * avx: _mm256_setr_pd, _mm256_setr_ps * avx: _mm256_setr_epi8 * avx: _mm256_setr_epi16 * avx: _mm256_setr_epi32, _mm256_setr_epi64x * avx: add missing assert_instr * avx: _mm256_set1_pd * avx: _mm256_set1_ps * avx: _mm256_set1_epi8 * avx: _mm256_set1_epi16, _mm256_set1_epi32 * avx: _mm256_set1_epi64x * avx: _mm256_castpd_si256, _mm256_castsi256_pd, _mm256_castps256_ps128, _mm256_castpd256_pd128, _mm256_castsi256_si128 * avx: remove assert_instr failing