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.

Sign up for GitHub

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

Jump to bottom

Implement raw fat pointer comparisons #1135

Merged
merged 1 commit into from
Sep 4, 2015
Merged

Implement raw fat pointer comparisons #1135

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 58 additions & 0 deletions text/0000-raw-pointer-comparisons.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
- Feature Name: raw-pointer-comparisons
- Start Date: 2015-05-27
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary

Allow equality, but not order, comparisons between fat raw pointers
of the same type.

# Motivation

Currently, fat raw pointers can't be compared via either PartialEq or
PartialOrd (currently this causes an ICE). It seems to me that a primitive
type like a fat raw pointer should implement equality in some way.

However, there doesn't seem to be a sensible way to order raw fat pointers
unless we take vtable addresses into account, which is relatively weird.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PartialOrd makes much more sense for raw slices *const [T] than for trait pointers, and the ordering is quite clear - (begin1, len1) < (begin2, len2).
(Speaking of weirdness, ordering for unrelated thin pointers doesn't make much sense too (C++, for example, doesn't even define it), but it exists just because having some ordering is useful.)


# Detailed design

Implement PartialEq/Eq for fat raw pointers, defined as comparing both the
unsize-info and the address. This means that these are true:

```Rust
&s as &fmt::Debug as *const _ == &s as &fmt::Debug as *const _ // of course
&s.first_field as &fmt::Debug as *const _
!= &s as &fmt::Debug as *const _ // these are *different* (one
// prints only the first field,
// the other prints all fields).
```

But
```Rust
&s.first_field as &fmt::Debug as *const _ as *const () ==
&s as &fmt::Debug as *const _ as *const () // addresses are equal
```

# Drawbacks

Order comparisons may be useful for putting fat raw pointers into
ordering-based data structures (e.g. BinaryTree).

# Alternatives

@nrc suggested to implement heterogeneous comparisons between all thin
raw pointers and all fat raw pointers. I don't like this because equality
between fat raw pointers of different traits is false most of the
time (unless one of the traits is a supertrait of the other and/or the
only difference is in free lifetimes), and anyway you can always compare
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on your version of equality there are other ways this can be true. If you ignore the vtables, and only compare the pointers (which is how I would define fat-ptr equality) then you can have two fat pointers of unrelated types which are equal:

let x = &T;
let a: &Tr1 = x;
let b: &Tr2 = x;
a == b

As long as T implements both Tr1 and Tr2, then the two traits do not have to be related in any way.

We haven't yet implemented casting from &Tr1 to &Tr1 + Tr2, so any cast would have to be to *u8 or something.

by casting both pointers to a common type.

It is also possible to implement ordering too, either in unsize -> addr
lexicographic order or addr -> unsize lexicographic order.

# Unresolved questions

See Alternatives.