Skip to content

Expose type_name() method on Any. #68379

New issue

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

#

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

Already on GitHub? # to your account

Jump to bottom
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
github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this issue Mar 11, 2025
@matthiaskrgr
Rollup merge of rust-lang#136148 - kpreid:type-str, r=joboet
f6853d3 
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
github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this issue Mar 11, 2025
@matthiaskrgr
Rollup merge of rust-lang#136148 - kpreid:type-str, r=joboet
b8795e9 
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
# for free to join this conversation on GitHub. Already have an account? # 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