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

Simplify dropck remark on PhantomData #125550

Closed

Conversation

workingjubilee
Copy link
Member

Fixes #125540

This is more similar to the original draft but there was a recommended change to the current form, along with injecting the caveat above it. I don't understand why, I found the previous phrasing more clear: "this indicates (thing) but (thing) matters only rarely".

r? @lcnr

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 25, 2024
/// `T` in very rare circumstances. This in turn has effects on the Rust compiler's [drop check]
/// analysis. For the exact rules, see the [drop check] documentation.
/// Currently, adding a field of type `PhantomData<T>` indicates the type *owns* data of type `T`.
/// In very rare circumstances, this has effects on the Rust compiler's [drop check] analysis.
Copy link
Member

@Noratrieb Noratrieb May 25, 2024

Choose a reason for hiding this comment

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

It still mentions the rare circumstances, so I don't think this fixes the issue. I don't like that sentence either. It should either be dropped, or explicitly mention those rare circumstances ("using the unstable may_dangle feature").

As long as we mention rare circumstances, we leave the reader puzzled what those circumstances may be.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm. My understanding is that the "rare circumstances" ambiguity comes about because the teams are hedging so they are allowed to change it.

My draft seems more acceptable to me than the status quo because it's unambiguous as to whether and when you should use PhantomData, it just is sly about whether it has any given effect.

Copy link
Contributor

Choose a reason for hiding this comment

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

cc #103413 (comment)

"Currently, adding a field of type PhantomData<T> indicates that your type owns data of type T in very rare circumstances" is intentional. Adding PhantomData<T> to your type only impacts whether your type 'owns' T in rare circumstances: if your type already has another field which requires drop:

struct DoesNotOwnT<T> {
   field: *const T,
   phantom_data: PhantomData<T>,
}
struct DoesOwnT<T> {
   field: *const T,
   other_field: String,
   phantom_data: PhantomData<T>,
}

Copy link
Contributor

@lcnr lcnr May 27, 2024

Choose a reason for hiding this comment

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

I've opened an RFC to fix this behavior rust-lang/rfcs#3417, but I currently don't have the capacity to push this over the finish line. See the examples in that RFC for more details

Copy link
Member Author

Choose a reason for hiding this comment

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

oic, thank you for explaining!

hmm... the definition provided here still feels abstruse, but I understand why you phrased it that way now.

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah 🤔 I think for this to make sense you'd have to actually go into the difference between needs_drop and dropck_outlives (PhantomData is only considered for dropck_outlives, as there shouldn't be any types for which needs_drop and Copy both hold)

Ideally the way we make this more understandable is by just merging rust-lang/rfcs#3417, though I guess we can also go more in-depth in the comment if you think that's more achievable.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm, I currently do not have an idea of how to proceed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PhantomData confusing documentation
4 participants