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.

[Dylan-DPC-zz]

Just an update: the linked pr has been merged

[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?