Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose type_name() method on Any. #68379

Open
rickvanprim opened this issue Jan 20, 2020 · 3 comments
Open

Expose type_name() method on Any. #68379

rickvanprim opened this issue Jan 20, 2020 · 3 comments
Labels
A-intrinsics Area: Intrinsics C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@rickvanprim
Copy link

In a similar spirit to #61533, it would be nice if the Any trait contained an auto implemented method akin to:

fn type_name(&self) -> &'static str
{
    std::any::type_name::<T>()
}

This way it would be a lot easier print and surface errors like accidentally trying to cast Box<T> to T because &Box<T> is also &Any.

@csmoe csmoe added A-intrinsics Area: Intrinsics C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jan 20, 2020
@steffahn
Copy link
Member

steffahn commented Dec 8, 2020

Something like this would be just as useful on Error. Would’ve been a huge help for this problem posted on URLO.

@eddyb
Copy link
Member

eddyb commented Apr 9, 2022

(cross-linking) TypeId containing a mangled name would allow this more efficiently (in terms of binary size) than via std::any::type_name, and is arguably necessary for sound TypeId (at least one some platforms?): #77125 (comment)

@eddyb
Copy link
Member

eddyb commented Apr 9, 2022

Update: finally opened #95845 with a (v0) mangling-based TypeId representation (which could eventually be used to allow runtime demangling of type names from TypeId and therefore Any).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-intrinsics Area: Intrinsics C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants