Add Invariant<T> marker type

[bluss]

From a discussion about different ways to write an Invariant type parameter marker; since we need to express it via PhantomData.

candidates were basically (although this was only used for &'a () cases)

1. PhantomData<*mut T>
2. PhantomData<Cell<T>>
3. PhantomData<fn(T) -> T>

Which all have different drawbacks and incidental other implications.

The source of the confusion was (3) case not passing my simple test for invariance.

Because of the drawbacks, it seems it would be useful to have a real invariance marker in rust's libstd.

(1) and (2) make the type !Sync. (2) has owns-T implications (3) has bug #31200. All of (1), (2), (3) don't respond like Invarant<T> should to custom new OIBITS.

cc @reem if you are interested.

[Gankra]

This seems like an RFCs thing.

I'm kinda ambivalent on this. We used to have these and that was confusing... but sometimes you do know exactly the semantic you want and there's no "natural" phantom for it.

[bluss]

It's more confusing to keep track of all incidental collaterals of the phantomdata formulations.

[nikomatsakis]

I'm sort of ambivalent as well. On the one hand, PhantomData is great when you DO have something that is, well, data that the compiler cannot see. On the other hand, sometimes you just need to track some types along, and in that case, the behavior of PhantomData can be kind of frustrating. I've wound up adding PhantomType to some projects of mine -- it's similar to the Invariant proposed here except that it adds covariance, but it doesn't make a big difference in practice. The main difference is that it is not supposed to represent "hidden data" but rather just "a type that I need to remember", which means it can e.g. be safely considered Send and so forth.

Anyway I agree this deserves an RFC.

[bluss]

RFC makes sense.

[pnkfelix]

Note also this important comment #31200 (comment) in response to the claim that "(3) has bug #31200"