Stabilize type_name_of_val
#118234
Merged
Stabilize type_name_of_val
#118234
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
|
No rustbot, I said that already @rustbot label -T-libs -T-compiler |
rustbot
removed
T-libs
1 task
|
cc implementer @lcnr |
Given that it's intended for diagnostics and the actual content isn't specified, I don't think is an issue at all. It can always be changed in the future. Big 👍 on stabilization, though. |
dtolnay
reviewed
Nov 25, 2023
dtolnay
added
S-waiting-on-fcp
tgross35
force-pushed
the
type_name_of_value
branch
from
de3848f
to
5222274
Compare
Make the following API stable:
// in core::any
pub fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str
Const stability is not added because this relies on `type_name` which is also
not const. That has a blocking issue.
Fixes rust-lang#66359
tgross35
force-pushed
the
type_name_of_value
branch
from
5222274
to
b225aab
Compare
dtolnay
removed
the
S-waiting-on-fcp
|
@bors r+ |
bors
added
the
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Dec 15, 2023
…lnay Stabilize `type_name_of_val` Make the following API stable: ```rust // in core::any pub fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str ``` This is a convenience method to get the type name of a value, as opposed to `type_name` that takes a type as a generic. Const stability is not added because this relies on `type_name` which is also not const. That has a blocking issue rust-lang#97156. Wording was also changed to direct most of the details to `type_name` so we don't have as much duplicated documentation. Fixes tracking issue rust-lang#66359. There were two main concerns in the tracking issue: 1. Naming: `type_name_of` and `type_name_of_val` seem like the only mentioned options. Differences in opinion here come from `std::mem::{size_of, align_of, size_of_val, align_of_val}`. This PR leaves the name as `type_name_of_val`, but I can change if desired since it is pretty verbose. 2. What this displays for `&dyn`: I don't think that having `type_name_of_val` function resolve those is worth the headache it would be, see rust-lang#66359 (comment) for some workarounds. I also amended the docs wording to leave it open-ended, in case we have means to change that behavior in the future. `@rustbot` label -T-libs +T-libs-api +needs-fcp r? libs-api
This was referenced Dec 15, 2023
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 15, 2023
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#117824 (Stabilize `ptr::{from_ref, from_mut}`) - rust-lang#118234 (Stabilize `type_name_of_val`) - rust-lang#118944 (Move type relations into submodule `relate` in rustc_infer, and notify when it has changed) - rust-lang#118977 (Simplify `src-script.js` code) - rust-lang#118985 (Remove `@JohnTitor` from diagnostics pings) - rust-lang#118986 (Simplify JS code a little bit) - rust-lang#118988 (rustdoc: add regression test for JS data file loading) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Dec 15, 2023
Rollup merge of rust-lang#118234 - tgross35:type_name_of_value, r=dtolnay Stabilize `type_name_of_val` Make the following API stable: ```rust // in core::any pub fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str ``` This is a convenience method to get the type name of a value, as opposed to `type_name` that takes a type as a generic. Const stability is not added because this relies on `type_name` which is also not const. That has a blocking issue rust-lang#97156. Wording was also changed to direct most of the details to `type_name` so we don't have as much duplicated documentation. Fixes tracking issue rust-lang#66359. There were two main concerns in the tracking issue: 1. Naming: `type_name_of` and `type_name_of_val` seem like the only mentioned options. Differences in opinion here come from `std::mem::{size_of, align_of, size_of_val, align_of_val}`. This PR leaves the name as `type_name_of_val`, but I can change if desired since it is pretty verbose. 2. What this displays for `&dyn`: I don't think that having `type_name_of_val` function resolve those is worth the headache it would be, see rust-lang#66359 (comment) for some workarounds. I also amended the docs wording to leave it open-ended, in case we have means to change that behavior in the future. ``@rustbot`` label -T-libs +T-libs-api +needs-fcp r? libs-api
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Make the following API stable:
This is a convenience method to get the type name of a value, as opposed to
type_namethat takes a type as a generic.Const stability is not added because this relies on
type_namewhich is also not const. That has a blocking issue #97156.Wording was also changed to direct most of the details to
type_nameso we don't have as much duplicated documentation.Fixes tracking issue #66359.
There were two main concerns in the tracking issue:
type_name_ofandtype_name_of_valseem like the only mentioned options. Differences in opinion here come fromstd::mem::{size_of, align_of, size_of_val, align_of_val}. This PR leaves the name astype_name_of_val, but I can change if desired since it is pretty verbose.&dyn: I don't think that havingtype_name_of_valfunction resolve those is worth the headache it would be, see Tracking issue forany::type_name_of_val#66359 (comment) for some workarounds. I also amended the docs wording to leave it open-ended, in case we have means to change that behavior in the future.@rustbot label -T-libs +T-libs-api +needs-fcp
r? libs-api