Skip to content

Commit e8819b6

Browse files
authored
Rollup merge of #68342 - lcnr:type_name_docs, r=Dylan-DPC
improve type_name_of_val docs suggested by @Globidev in #66359 (comment)
2 parents 6c94ceb + 6b7f3e5 commit e8819b6

File tree

1 file changed

+5
-1
lines changed

1 file changed

+5
-1
lines changed

src/libcore/any.rs

+5-1
Original file line numberDiff line numberDiff line change
@@ -476,11 +476,15 @@ pub const fn type_name<T: ?Sized>() -> &'static str {
476476
///
477477
/// This is intended for diagnostic use. The exact contents and format of the
478478
/// string are not specified, other than being a best-effort description of the
479-
/// type. For example, `type_name_of::<Option<String>>(None)` could return
479+
/// type. For example, `type_name_of_val::<Option<String>>(None)` could return
480480
/// `"Option<String>"` or `"std::option::Option<std::string::String>"`, but not
481481
/// `"foobar"`. In addition, the output may change between versions of the
482482
/// compiler.
483483
///
484+
/// This function does not resolve trait objects,
485+
/// meaning that `type_name_of_val(&7u32 as &dyn Debug)`
486+
/// may return `"dyn Debug"`, but not `"u32"`.
487+
///
484488
/// The type name should not be considered a unique identifier of a type;
485489
/// multiple types may share the same type name.
486490
///

0 commit comments

Comments
 (0)