Skip to content

The type_name of tuple-structs and their ZST function item are the same #84666

Closed
@scottmcm

Description

@scottmcm

I tried this code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=f6fa0a5aa4d0a3d422c2db601a77c304

use std::any::type_name;

struct Velocity(f32, f32);

fn show_name<T>(_: T) {
    dbg!(type_name::<T>());
}

fn main() {
    show_name(Velocity);
    show_name(Velocity(0.0, -9.8));
}

I expected to see this happen:
The two names would be different, so that in logging I'd be able to notice I passed the wrong thing.

Instead, this happened:

[src/main.rs:6] type_name::<T>() = "playground::Velocity"
[src/main.rs:6] type_name::<T>() = "playground::Velocity"

Context:
This came up in the bevy discord server: https://discord.com/channels/691052431525675048/742884593551802431/836883497578397706

It allows you to put an instance of anything as a component on an entity, and get it back again later by type. So passing in a struct Marker; instance is fine -- and useful for filtering -- but it can't tell the difference between useful ZSTs like that and accidental ZSTs like Velocity where they meant to pass Velocity::new(). It would be nice for that to be at least available in debug logging, as a way to see what's available, but if that shows "Velocity" then it'd be particularly confusing when the "give me a ::<Velocity>()" doesn't work.

I'm not proposing any concrete string that this should return; it'd just be nice for it to be better distinguished.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.T-libsRelevant to the library team, which will review and decide on the PR/issue.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions