Rephrase the any::type_name docs a bit.

This attempts to be a little clearer (including in terminology) about the lack
of guarantees that any::type_name provides.

1 files changed, 7 insertions, 7 deletions

diff --git a/src/libcore/any.rs b/src/libcore/any.rs
index 39df803bbea..67698e5409f 100644
--- a/src/libcore/any.rs
+++ b/src/libcore/any.rs
@@ -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.