Skip to content

Commit

Permalink
Rephrase the any::type_name docs a bit.
Browse files Browse the repository at this point in the history
This attempts to be a little clearer (including in terminology) about the lack
of guarantees that any::type_name provides.
  • Loading branch information
ltratt committed May 4, 2020
1 parent ff4df04 commit c9f1162
Showing 1 changed file with 7 additions and 7 deletions.
14 changes: 7 additions & 7 deletions src/libcore/any.rs
Expand Up @@ -446,14 +446,14 @@ impl TypeId {
/// # Note
///
/// This is intended for diagnostic use. The exact contents and format of the
/// string are not specified, other than being a best-effort description of the
/// type. For example, `type_name::<Option<String>>()` could return the
/// `"Option<String>"` or `"std::option::Option<std::string::String>"`, but not
/// `"foobar"`. In addition, the output may change between versions of the
/// compiler.
/// string retrned are not specified, other than being a best-effort description
/// of the type. For example, amongst the strings
/// that `type_name::<Option<String>>()` might map to are `"Option<String>"` and
/// `"std::option::Option<std::string::String>"`.
///
/// The type name should not be considered a unique identifier of a type;
/// multiple types may share the same type name.
/// The returned string must not be considered to be a unique identifier of a
/// type as multiple types may map to the same type name. In addition, the
/// output may change between versions of the compiler.
///
/// The current implementation uses the same infrastructure as compiler
/// diagnostics and debuginfo, but this is not guaranteed.
Expand Down

0 comments on commit c9f1162

Please sign in to comment.