Tracking issue for any::type_name_of_val

[lcnr]

#65961 added the function core::any::type_name_of_val.

Unresolved issues:

• type_name_of_val(&val) is quite verbose, type_name_of(&val) might be better, even if align_of, align_of_val and size_of and size_of_val already exist.

[Globidev]

It might be worth considering adding a note about the usage of dyn Traits with that function.

core::mem::size_of_val will actually inspect a DST's metadata to return an appropriate value for the size but core::any::type_name_of_val cannot do the same since AFAIK vtables include size and alignment information, but no type name.

Some users might get confused as to why type_name_of_val(&some_dyn_foo) returns "dyn Foo" and not the actual type name of the unsized type

[lcnr]

used in a question on reddit

[Fishrock123]

Would something like type_name_dynamic() be acceptable? Right now I am literally just copying rustc's existing impl into my code, haha.

[lcnr]

One big issue of type_name_of_val is that it does not look into trait objects, so for example

#![feature(type_name_of_val)]

fn main() {
    let x: u32 = 3;
    let y: &dyn Send = &x;
    println!("{}", std::any::type_name_of_val(y)); // prints something like 'dyn Send'
}

I think dynamic quite strongly implies that it does look into trait objects so I don't feel like this name would be a good fit here

[Fishrock123]

Perhaps type_name_of_generic()?

Or are we saying that this should be changed to get type name form dynamic objects at runtime?

[lcnr]

getting the type name at runtime isn't really possible without having a non zero cost even for programs never using type_name_of_val

type_name_of_generic is even more verbose than type_name_of_val so I personally do not prefer it. Don't really care about this though

[Fishrock123]

Perhaps type_name_of, and then in a theoretical future type_name_of_val could do the dynamic thing.

[mehcode]

Just tried to use this for what it says on the tin. It wasn't able to work for my situation. I'm trying to print the type name of a partially-moved struct.

type_name_of_val(&expr);

error[E0382]: borrow of partially moved value: `expr`

Does this need to be compiler magic to let this work?

[Globidev]

@mehcode
This is indeed a general issue with partially moved values: you cannot create a reference to one
&expr would always be invalid and yield that error, regardless of the surrounding context.
it would also probably lead to more confusion if we were to somehow allow this to work in this particular case

[danielhenrymantilla]

@mehcode you can write the following helper to let you query the type name of an unusable binding:

macro_rules! type_name_of {( $e:expr $(,)? ) => ({
    let it = [];
    #[allow(unreachable_code)] {
        if false {
            loop {} // disables borrowck and dropck
            (&mut { it })[0] = &$e; // nudges type inference
        }
    }
    $crate::__helper__(it)
})} pub(in crate) use type_name_of;

#[doc(hidden)] pub
fn __helper__<T> (_: [&T; 0])
  -> &'static str
{
    ::core::any::type_name::<T>()
}

With it, the following snippet compiles and runs fine:

let it = (vec![()], 42);
drop(it.0);
dbg!(type_name_of!(it));

• Playground

[tgross35]

Is the only blocker here naming? It seems like type_name_of_val and type_name_of are the two possibilities. std::mem::{align_of_val, size_of_val} do use of_val, but their base names also already have _of so there is already a difference (this base function is type_name not type_name_of).

I don't think that there is much we would want to do for arbitrary &dyn without adding some amount of bloat to trait objects. This seems better as a helper trait:

trait AnyNamed {
    fn name(&self) -> &'static str {
        std::any::type_name::<Self>()
    }
}

impl<T: ?Sized> AnyNamed for T {}

fn type_name_dyn(val: &dyn AnyNamed) {
    println!("{}", val.name());
}

fn main() {
    type_name_dyn(&"abcd".to_owned()); // alloc::string::String
    type_name_dyn(&100u8); // u8
    type_name_dyn(&10.0f32); // f32
}

Or, if you only need a few types you can just check if your &dyn Any matches one

macro_rules! dyn_impl {
    ($val:ident, $($ty:ty),*) => { $(
        if $val.is::<$ty>() {
            stringify!($ty)
        } else )* {
            "unknown"
    }}
}

fn type_name_dyn(val: &dyn std::any::Any) {
    let name = dyn_impl!(val, String, u8, f32);
    println!("{name}");
}

fn main() {
    type_name_dyn(&"abcd".to_owned()); // String
    type_name_dyn(&100u8); // u8
    type_name_dyn(&10.0f32); // f32
    type_name_dyn(&"abcd"); // unknown
}

[tgross35]

I created a stabilization PR at #118234

[dtolnay]

@rust-lang/libs-api:
@rfcbot fcp merge

https://doc.rust-lang.org/nightly/core/any/fn.type_name_of_val.html

Context: this function is intended to be useful when you have a value whose type cannot be named in Rust code, so directly calling type_name::<T>() is not straightforward. Examples: function objects, or impl Trait values.

fn main() {
    println!("{}", type_name_of_val(&main));  // "playground::main"
    f(false);
}

fn f(asdf: impl Display) {
    println!("{}", type_name_of_val(&asdf));  // "bool"
}

Stabilizing type_name_of_val does not add any expressiveness, since it is a trivial wrapper that is easy to implement yourself. We would only be adding convenience. People needing type_name_of_val today wouldn't be desperate to get this stabilized in core, since they would just be writing their own:

fn type_name_of_val<T: ?Sized>(_: &T) -> &'static str {
    type_name::<T>()
}

Notes from @tgross35 in #118234 (comment):

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.

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 #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.

Const stability is not added because this relies on type_name which is also not const. That has a blocking issue #97156.

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.