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

Tracking Issue for #![feature(phantom_variance_markers)] #135806

Open
2 of 4 tasks
jhpratt opened this issue Jan 21, 2025 · 7 comments
Open
2 of 4 tasks

Tracking Issue for #![feature(phantom_variance_markers)] #135806

jhpratt opened this issue Jan 21, 2025 · 7 comments
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@jhpratt
Copy link
Member

jhpratt commented Jan 21, 2025

Feature gate: #![feature(phantom_variance_markers)]

This is a tracking issue for phantom variance markers, which are identical to PhantomData but provide a self-documenting variance rather than contrived types such as PhantomData<fn() -> T> to indicate contravariance.

Public API

// in core::marker

pub struct PhantomCovariant<T: ?Sized>(/* ... */);
pub struct PhantomInvariant<T: ?Sized>(/* ... */);
pub struct PhantomContravariant<T: ?Sized>(/* ... */);
pub struct PhantomCovariantLifetime<'a>(/* ... */);
pub struct PhantomInvariantLifetime<'a>(/* ... */);
pub struct PhantomContravariantLifetime<'a>(/* ... */);

pub trait Variance: Sealed {}
impl<T: ?Sized> Variance for PhantomCovariant<T> {}
impl<T: ?Sized> Variance for PhantomInvariant<T> {}
impl<T: ?Sized> Variance for PhantomContravaiant<T> {}
impl<T: ?Sized> Variance for PhantomCovariantLifetime<T> {}
impl<T: ?Sized> Variance for PhantomInvariantLifetime<T> {}
impl<T: ?Sized> Variance for PhantomContravaiantLifetime<T> {}

pub fn variance<T: Variance>() -> T {}

// also the trait impls you would expect; identical to PhantomData

Steps / History

Unresolved Questions

  • Should there be a single Lifetime type or one for each possible variance? The former would mean writing PhantomCovariant<Lifetime<'a>> instead of PhantomCovariantLifetime<'a>, with the API otherwise being identical.
  • Should the values be directly constructable, eliminating the need for ::new()? This would presumably mean adding 4–6 lang items, depending on the previous bullet point.
  • Are we happy exposing the (unstable) rustc_pub_transparent on these, allowing indirect inclusion in repr(transparent) types?

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html

@jhpratt jhpratt added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jan 21, 2025
jhpratt added a commit to jhpratt/rust that referenced this issue Jan 27, 2025
@QuineDot
Copy link

As a note for future consideration: since lifetimes are not types, it's somewhat arbitrary to say whether e.g. &T is covariant in the lifetime or contravariant in the lifetime. Today saying covariant is the norm, but it used to be contravariant, and some people feel contravariant is the more sensible terminology.

Stabilizing all of the current names would lock in the choice. (Which may be fine, but should be a conscious decision.)

((The Invariant versions don't lock in the choice.))

@ChrisDenton
Copy link
Member

Maybe we should try to come up with some new terminology if it's arbitrary anyway? I have heard people say they have to look up what covariant and contravariant mean (in terms of lifetime) every single time because it can be hard to keep in ones head.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jan 27, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jan 27, 2025
Rollup merge of rust-lang#135807 - jhpratt:phantom-variance, r=Amanieu

Implement phantom variance markers

ACP accepted rust-lang/libs-team#488

Tracking issue rust-lang#135806
@Sky9x
Copy link
Contributor

Sky9x commented Jan 30, 2025

Just ran into a slight hiccup with this feature: using these marker types in a #[repr(transparent)] struct throws the future-incompatibility lint repr_transparent_external_private_fields.

Example (playground):

#![feature(phantom_variance_markers)]

use std::marker::PhantomCovariantLifetime;
use std::ptr::NonNull;

#[repr(transparent)]
pub struct Foo<'a, T> {
    inner: NonNull<T>,
    _marker: PhantomCovariantLifetime<'a>,
}
warning: zero-sized fields in `repr(transparent)` cannot contain external non-exhaustive types
 --> src/lib.rs:9:5
  |
9 |     _marker: PhantomCovariantLifetime<'a>,
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #78586 <https://github.com/rust-lang/rust/issues/78586>
  = note: this struct contains `PhantomCovariantLifetime<'a>`, which contains private fields, and makes it not a breaking change to become non-zero-sized in the future.
  = note: `#[warn(repr_transparent_external_private_fields)]` on by default

warning: `playground` (lib) generated 1 warning

@jhpratt
Copy link
Member Author

jhpratt commented Jan 31, 2025

😔 some day we'll get #[repr(pub transparent)] or something to that effect. I didn't realize it was future incompat warning, though.

@lukas-code
Copy link
Member

some day we'll get #[repr(pub transparent)]

We do have #[rustc_pub_transparent] and putting that on the Phantom* types should silence the warning.

@jhpratt
Copy link
Member Author

jhpratt commented Feb 13, 2025

Thanks @lukas-code — I'll get to that tonight 👍

@jhpratt
Copy link
Member Author

jhpratt commented Feb 15, 2025

Apparently I forgot to mark them #[repr(transparent)] at all, let alone publicly. Either way, #137054 is now open.

github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this issue Mar 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants