Implement raw fat pointer comparisons

[arielb1]

Rendered

[petrochenkov]

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.)

[Aatch]

It would be good to either make it more obvious this is specific to fat pointers, or explain that equality and ordering already exist for thin pointers (of the same type at least). The way it's current written made me think that you were suggesting removing ordering from all raw pointers.

[nrc]

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.

[nrc]

I think there is a deep question here which is, should we be able to compare pointers which point to different types. If we think yes, then we should allow heterogeneous fat ptr comparison. If not, then we should not allow any fat ptr comparison, since the 'real' type of a fat pointer is not known, so we might be comparing pointers to different types.

I think the answer should be 'yes' for raw pointers, I don't see much of a downside. These are comparisons of the pointer, not the value pointed to, so they are clearly comparable things. I think we can afford to be a little less 'safe' here since we are only talking about raw pointers. I can imagine we might not allow any comparison (since we don't allow arithmetic) but if we are going to allow comparison I don't see why there should be a type restriction.

The other point is whether we should involve the vtables (or array lengths) in the comparison. I think we should not do this. The organisation of the vtable is an implementation detail that we may change, so it should not be exposed in any way to the programmer.

[zkamsler]

I think you would have to include the vtable pointer in the comparison. For trait objects pointing to zero-sized types, the address of the fat pointer might be a sentinel (depending on allocator behavior).

[zkamsler]

Similarly, a struct and the first field in a struct could implement the same trait. Thus, the address could be the same, but the vtable would vary. (which I now see is explicitly mentioned in the RFC)

[comex]

What would be the defined semantics for this with zero-sized types?

(I don't like implicitly-supported pointer comparisons in general, since they make difficult a potential future optimization to represent &T as T where T is pointer-sized or less...)

[zkamsler]

@comex
I would expect it to be the same as for non-zero sized types. There is still an address and a vtable/count. A raw pointer would be equal iff both are equal. The address is just less likely to be unique.

[nikomatsakis]

@comex well, &T and *T are very different, right? In particular, this RFC does not describe &T comparisons. (unless I missed something)

[nrc]

I had thought that we should look only at the pointers for all kinds of comparison, but looking at the vtables too also seems a reasonable approach. In particular if two pointers have different vtables they would be not equal and could not be compared for ordering. I don't have a strong preference for either kind of comparison; including the vtables seems marginally superior.

[llogiq]

Another related thing is that for some HPC use cases, pointer equality is often a useful property.

[pythonesque]

This would be extremely useful. I'm very much in favor.

[nikomatsakis]

Hear ye, hear ye. This RFC is now entering final comment period.

[nrc]

@arielb1 there's a few comments in the thread about whether to include the vtable info in the comparison, to you have an opinion beyond what is in the RFC? I just wanted to check you didn't have more thoughts here, otherwise we (lang team) think this is ready to merge.

[arielb1]

@nrc

that's it, merge the RFC as is (comparing vtable addresses), and prohibit PartialOrd?

[nikomatsakis]

I definitely think vtables should be part of the comparison. Two examples:

1. A pointer to a struct and a pointer to its field field should not be equal. :)
2. In general, if the vtable is unequal, it means some types are unequal, so even if it is the same memory, it must be being interpreted differently, or else a subset of that memory (as in case 1). The behavior will not be the same when you use the object, so why should it be equal? If you had static type information (a thin pointer), you couldn't even compare the two pointers, as you'd get a type error. So overall, doesn't make sense to me.

(We discussed this in the lang team meeting, these points were raised there.)

[arielb1]

@nikomatsakis

That was my initial thought too. What should happen with PartialOrd through? I am afraid that banning it would weaken inference in the foo as *const _ < bar as *const _ case. Maybe casts should be obligations - that would fix it.

[nikomatsakis]

@arielb1

casts should be obligations

Yes, I think the current system is just a poor man's obligation. I personally have no problem supporting PartialOrd -- it seems no more dubious than PartialOrd on other * pointers. You can hardly expect that to be stable across executions, but it's otherwise rather useful.

[arielb1]

@nikomatsakis

[bikeshed] is the vtable or addr more significant?

[nikomatsakis]

@arielb1 whichever comes first in our current representation :)

[nikomatsakis]

Huzzah! The language design subteam has decided to accept this RFC. The canonical text is now in the repository and the tracking issue for implementation is at rust-lang/rust#28236.

Note: there is still an unresolved question, perhaps suitable for a followup RFC or amendment, about ordering beyond equality.