Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A core trait for shallow/pointer equality #4012

Closed
bstrie opened this issue Nov 21, 2012 · 7 comments
Closed

A core trait for shallow/pointer equality #4012

bstrie opened this issue Nov 21, 2012 · 7 comments
Labels
A-trait-system Area: Trait system C-enhancement Category: An issue proposing an enhancement or a PR with one. P-low Low priority

Comments

@bstrie
Copy link
Contributor

bstrie commented Nov 21, 2012

< Dzmitry> I have 2 pointers to a shared structure (@). How do I know it's the
           same structure?
< Dzmitry> comparing this pointers issues a compile error saying that @Eq is not
           implemented for the structure
<@pcwalton> Dzmitry: box::ptr_eq
<@pcwalton> Eq is deep
<@pcwalton> there is a separate method for it
<@pcwalton> "it" == shallow comparison
< Dzmitry> pcwalton: interesting. But what if my pointers are wrapped in
           Option<>, can I compare two options by ptr_eq?
<@pcwalton> no, you can't at the moment
<@pcwalton> probably PtrEq or ShallowEq should be a trait like Eq
<@pcwalton> and then implemented on Option<T>
@pnkfelix
Copy link
Member

I don't think this is a backwards-compatibility issue. (We should be able to add a ShallowEq trait later.)

I do agree that we probably want this.

Re-nominating for milestone #5: Production Ready.

@glaebhoerl
Copy link
Contributor

FWIW is ptr_eq safe in the presence of potentially moving GC? In Haskell they call it reallyUnsafePtrEquality# for that reason among others, and while Rust's functions aren't required to be pure (so it wouldn't be unsafe in the Rust sense), do similar concerns apply?

@pnkfelix
Copy link
Member

@glehel A safe pointer-equality operation can definitely be implemented in a moving GC. One can look for example at how the eq? operation is implemented in Scheme runtime systems.

The place where I would anticipate issues with a moving GC would be unsafe casts from pointers to integers, as one would do e.g. for a pointer-based hashcode operation. So if one wanted a hashtable based on memory address that could use @ptrs as keys, then that hashtable implementation would need to be tied to the moving GC implementation. (See e.g. Larceny's hashtable implementation for an example; that is an example of language implementation that takes pains to not allow safe code to extract identify-based hash codes from arbitrary objects, the way that one can in Java via System.identityHashCode, though some Scheme systems do not take similar pains)

@graydon
Copy link
Contributor

graydon commented Jul 18, 2013

accepted for feature-complete milestone

@pnkfelix
Copy link
Member

assigning P-low.

@thestinger
Copy link
Contributor

The ref_eq/ptr_eq methods for references and Rc were completely removed... I'm not sure if that decision was a good one, but it doesn't make sense to add a trait if even a standalone method isn't wanted.

@thestinger
Copy link
Contributor

Rust moved away from providing these functions at all, so a trait doesn't make sense anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trait-system Area: Trait system C-enhancement Category: An issue proposing an enhancement or a PR with one. P-low Low priority
Projects
None yet
Development

No branches or pull requests

5 participants