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.

Sign up for GitHub

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

Jump to bottom

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 eddyb mentioned this issue Apr 9, 2022
Closed
@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).

@kpreid kpreid mentioned this issue Jan 27, 2025
Merged
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Feb 20, 2025
@workingjubilee
Rollup merge of rust-lang#136148 - kpreid:type-str, r=joboet
e813506 
Optionally add type names to `TypeId`s.

This feature is intended to provide expensive but thorough help for developers who have an unexpected `TypeId` value and need to determine what type it actually is. It causes `impl Debug for TypeId` to print the type name in addition to the opaque ID hash, and in order to do so, adds a name field to `TypeId`. The cost of this is the increased size of `TypeId` and the need to store type names in the binary; therefore, it is an optional feature. It does not expose any new public API, only change the `Debug` implementation.

It may be enabled via `cargo -Zbuild-std -Zbuild-std-features=debug_typeid`. (Note that `-Zbuild-std-features` disables default features which you may wish to reenable in addition; see
<https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features>.)

Example usage and output:

```
fn main() {
    use std::any::{Any, TypeId};
    dbg!(TypeId::of::<usize>(), drop::<usize>.type_id());
}
```

```
TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize)
drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>)
```

Also added feature declarations for the existing `debug_refcell` feature so it is usable from the `rust.std-features` option of `config.toml`.

Related issues:

* rust-lang#68379
* rust-lang#61533
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 21, 2025
@matthiaskrgr
Rollup merge of rust-lang#136148 - kpreid:type-str, r=joboet
28164f1 
Optionally add type names to `TypeId`s.

This feature is intended to provide expensive but thorough help for developers who have an unexpected `TypeId` value and need to determine what type it actually is. It causes `impl Debug for TypeId` to print the type name in addition to the opaque ID hash, and in order to do so, adds a name field to `TypeId`. The cost of this is the increased size of `TypeId` and the need to store type names in the binary; therefore, it is an optional feature. It does not expose any new public API, only change the `Debug` implementation.

It may be enabled via `cargo -Zbuild-std -Zbuild-std-features=debug_typeid`. (Note that `-Zbuild-std-features` disables default features which you may wish to reenable in addition; see
<https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features>.)

Example usage and output:

```
fn main() {
    use std::any::{Any, TypeId};
    dbg!(TypeId::of::<usize>(), drop::<usize>.type_id());
}
```

```
TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize)
drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>)
```

Also added feature declarations for the existing `debug_refcell` feature so it is usable from the `rust.std-features` option of `config.toml`.

Related issues:

* rust-lang#68379
* rust-lang#61533
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Feb 21, 2025
@rust-timer
Unrolled build for rust-lang#136148
fe4c3f3 
Rollup merge of rust-lang#136148 - kpreid:type-str, r=joboet

Optionally add type names to `TypeId`s.

This feature is intended to provide expensive but thorough help for developers who have an unexpected `TypeId` value and need to determine what type it actually is. It causes `impl Debug for TypeId` to print the type name in addition to the opaque ID hash, and in order to do so, adds a name field to `TypeId`. The cost of this is the increased size of `TypeId` and the need to store type names in the binary; therefore, it is an optional feature. It does not expose any new public API, only change the `Debug` implementation.

It may be enabled via `cargo -Zbuild-std -Zbuild-std-features=debug_typeid`. (Note that `-Zbuild-std-features` disables default features which you may wish to reenable in addition; see
<https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features>.)

Example usage and output:

```
fn main() {
    use std::any::{Any, TypeId};
    dbg!(TypeId::of::<usize>(), drop::<usize>.type_id());
}
```

```
TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize)
drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>)
```

Also added feature declarations for the existing `debug_refcell` feature so it is usable from the `rust.std-features` option of `config.toml`.

Related issues:

* rust-lang#68379
* rust-lang#61533
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
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
Milestone
No milestone
Development

No branches or pull requests
4 participants
@eddyb @steffahn @rickvanprim @csmoe