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

Extend C-DEREF guideline to say smart pointers should always be transparent in Debug representation #168

Open
dtolnay opened this issue May 17, 2018 · 7 comments
Open

Extend C-DEREF guideline to say smart pointers should always be transparent in Debug representation #168

dtolnay opened this issue May 17, 2018 · 7 comments
Labels
amendment Amendments to existing guidelines disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. T-libs Relevant to the libraries subteam, which will review and decide on the PR/issue.

Comments

@dtolnay
Copy link
Member

dtolnay commented May 17, 2018

The canonical Debug implementation for any type that implements Deref is:

Debug::fmt(&**self, formatter)

This principle came up during libs team discussion of rust-lang/rust#48553.
@KodrAus KodrAus added amendment Amendments to existing guidelines disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. labels Dec 22, 2020
@KodrAus
Copy link
Contributor

KodrAus commented Dec 22, 2020

Seems reasonable to me!

@KodrAus

This comment has been minimized.

Sign in to view
@KodrAus KodrAus added the T-libs Relevant to the libraries subteam, which will review and decide on the PR/issue. label Dec 22, 2020
@KodrAus
Copy link
Contributor

KodrAus commented Dec 22, 2020

@rfcbot fcp merge

This suggests a guideline that smart pointers inherit the Debug implementation of their pointee.

@rfcbot
Copy link

rfcbot commented Dec 22, 2020 •
edited by Amanieu

Team member @KodrAus has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot
Copy link

rfcbot commented Dec 31, 2020

🔔 This is now entering its final comment period, as per the review above. 🔔

psst @KodrAus, I wasn't able to add the final-comment-period label, please do so.

@rfcbot
Copy link

rfcbot commented Jan 10, 2021

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

psst @KodrAus, I wasn't able to add the finished-final-comment-period label, please do so.

@KodrAus KodrAus added the finished-final-comment-period The final comment period is finished for this PR / Issue. label Jan 12, 2021
@jonhoo
Copy link

jonhoo commented Dec 15, 2023

Given this passed FCP, should the change be made?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
amendment Amendments to existing guidelines disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. T-libs Relevant to the libraries subteam, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jonhoo @dtolnay @KodrAus @rfcbot