Expose the type_name intrinsic

[sfackler]

We have an intrinsic which returns a &'static str naming a type but it's not exposed in a safe/stable manner anywhere: http://doc.rust-lang.org/std/intrinsics/fn.type_name.html

Something like this should suffice:

pub fn type_name<T: Reflect + ?Sized>() -> &'static str {
     unsafe { std::intrinsics::type_name::<T>() }
}

[nagisa]

What is the usecase for this?

Probably would be good for diagnostics/panic messages in libraries. E.g. .unwrap() would be so much better if it said “called unwrap() on a None variant of Option<MonoType>” IMO. Exposing this would allow making similar messages possible in libraries.

@sfackler why the Reflect bound?

[sfackler]

We use bounds like Any and Reflect to make sure that people are opting into paramicity violations. Getting a name of a type might be harmless enough that we could drop the bound, though.

Thoughts, @rust-lang/libs?

[durka]

I think you would have to drop the bound for that example to be workable, no? Option::<T>::unwrap would need to add a T: Reflect bound and that's a breaking change AFAIK. Edit: guess not.

[Gankra]

I would ditch the reflect bound, but I'm not actually that familiar with our current reflection strategy. If this makes it incoherent, that's bad.

I am slightly terrified that people will use this to impl adhoc name-based specialization.

[sfackler]

You can already do that in a less messed up way by comparing TypeIds.

[jonas-schievink]

@ticki macros don't have type information and don't work in generic contexts

[aturon]

@sfackler It needs the Reflect bound, or else Reflect really isn't doing much for us :)

That said, Reflect is likely going away anyway, if specialization lands.

[jonas-schievink]

OTOH mem::size_of already violates parametricity

[aturon]

@jonas-schievink Indeed, but in a much "lossier" way. (FWIW, I'm not terribly fond of the whole Reflect business in any case, but until we deprecate it, we should at least not introduce new leaks.)

[brson]

I don't even see anywhere in-tree where this is used except test cases. It was added in rust-lang/rust@e256b7f but even then didn't appear to be used.

Please lets come up with a concrete use case and use it, not just add the feature speculatively.

[sfackler]

@brson I opened this issue because it was a thing I wanted to use for a concrete use case.

Specifically, rust-postgres reports this error when the user attempts to convert a Postgres value to an incompatible Rust value or vice versa, for example a Postgres VARCHAR to a Rust i32, but right now all it can say is that a value of type VARCHAR could not be converted to... something. If type_name was stable, I could stick a &'static str in that error type and be set.

[ranma42]

I would expect more something like

 // no need for Reflection, resolved at compile time, possibly make it even const
pub fn type_name<T>() -> &'static str
 // resolved dynamically, hence needs reflection, no obvious need for size bound
pub fn type_name_of_val<T: Any>(val: &T) -> &'static str

The former would be convenient when generating error messages as pointed out by @nagisa.
I expect the latter to be used in conjunction with Any, in order to provide a better error message when a downcast_{ref,mut} fails (in a way, this would provide a "string" version of TypeId):

pub fn downcast<'a, T: Any>(x: &'a Any) -> Result<&'a T, String> {
    match x.downcast_ref() {
        Some(y) => Ok(y),
        None => Err(format!("got {}, expected {}", type_name_of_val(x), type_name<T>())),
    }
}

[glaebhoerl]

@ranma42 You can implement type_name_of_val using type_name without requiring an Any constraint, so I don't think this is the right distinction to make.

One distinction I think we should make is between things which exist for debugging/development purposes and things which are used for implementing "actual/intended program behavior". I think it's totally fine to pierce whatever abstraction boundaries you want in the former case, and not at all in the latter. Of course, how to prevent things intended for the former from being abused for the latter is an interesting question, but even Haskell has Debug.Trace which does IO inside pure code, but "only for debugging purposes".

So that then raises the question of what type_name is for. If it's mainly a debugging aid (I think you could plausibly argue that emitting better error messages falls in this category, even if that's something which is observable runtime behavior), then having it be constraint-free seems fine. On the other hand, if actual program logic is going to rely on it in some way, then I strongly believe it should require a Reflect/Any constraint (this kind of thing is what they exist for).

[ranma42]

@glaebhoerl I might be missing something (in particular, the signature I used on the function is possibly wrong), but in my mind the purpose for type_name_of_val would be to obtain the type of a value wrapped in a fat pointer. This type might depend on the actual execution (for example a &Any reference might point to an Option::<u32> or to a u32 indifferently). How could this be implemented using type_name?