std::any::TypeId <-> u64?

[H2CO3]

@zeroexcuses

What is?

Assuming that I am disconnected from reality.

@zeroexcuses

If there is a logical flaw in my argument

Your assumption about this not being real was plainly wrong because the exact behavior you think isn't real is being worked on currently with the very real intention of introducing it soon, even as a deliberately breaking change.

[jbe]

@zeroexcuses

How can the docs claim it to be globally unique if it's the hash of something ?

I think it's reasonable to claim a hash is unique if it's really long enough and uses a suitable one-way function. That is at least 256 bits output (better 512), and using a cryptographically secure hash function. ^[1]

Afterall, all real-world processes are subject to probability (e.g. there is also a certain very low probability that the bits flip in a CPU). I mention this to justify that "very very low probability" can be safely assumed to be "practically zero".

However, TypeId is not long enough currently, and I find it sad that it's not documented, given that issue #10389 is almost 10 years old . Not everyone knows every bug in the tracker.

---

1. If the hash function is broken (in which case collisions could be deliberately created with a higher probability), this becomes untrue of course, unless the hash function can be replaced with a non-broken one. ↩︎

[zeroexcuses]

@H2CO3

Assuming that I am disconnected from reality.

This is what I wrote:

@zeroexcuses

It sounds like you are optimizing for a NOT-YET-REALITy world where TypeID is changed from u64 to something longer than a Sha256.

I think you extrapolated that into something else and got offended by that (the thing you extrapolated to).

@H2CO3

Your assumption about this not being real was plainly wrong because the exact behavior you think isn't real is being worked on currently with the very real intention of introducing it soon, even as a deliberately breaking change.

I think it is logically correct to describe that as "not yet reality" (with respect to current rustc as of Aug 8 2022) -- it may be worked on, but it is not yet reality.

[H2CO3]

@zeroexcuses

I think it is logically correct to describe that as "not yet reality"

You are splitting hairs and trying to sound very formal and very logical, but you are doing this at the expense of taking some reasonable advice from your peers. That's your choice, but it's a weird one given that you were asking the question (and several follow-ups).

I have repeatedly observed this behavior on your part, and I have to say, it's getting annoying after a long time. You are asking questions each day, sometimes several ones in quick succession, seemingly trying to accomplish big things (while not yet having the foundational knowledge for them), and yet you soon start debating and questioning every last bit of advice you get from others, as if this were some sort of a mathematics, formal logic, or philosophy class, or debate contest.

At this point I find it very hard to imagine any sort of legitimate reason behind this behavior (let alone tolerate it), and want to very clearly point out that this kind of conduct ends up wasting the time of the several people who are genuinely trying to help you. If you can't or don't want to take advice, then don't ask questions. Don't go around actively asking people, just in order to be able to call them wrong left and right, because that comes off as malice.

Accordingly, I'm not going to reply to this thread anymore, and I'm not sure if I ever want to interact with you on this platform in any other way.

[zeroexcuses]

@H2CO3

You are asking questions each day, sometimes several ones in quick succession, seemingly trying to accomplish big things (while not yet having the foundational knowledge for them), and yet you soon start debating and questioning every last bit of advice you get from others, as if this were some sort of a mathematics, formal logic, or philosophy class, or debate contest.

Two (of many) ways to learn from online forums:
(1) you take whatever some stranger on the internet tells you at face value as gospel,
(2) you disassemble every idea to it's primitive pieces an put it back together again.

I have picked the latter, and it appears this offends you.

@H2CO3

At this point I find it very hard to imagine any sort of legitimate reason behind this behavior (let alone tolerate it), and want to very clearly point out that this kind of conduct ends up wasting the time of the several people who are genuinely trying to help you. If you can't or don't want to take advice, then don't ask questions.

This is a strawman. I am currently using @quinedot 's sorting based solution. See:

pub struct Cos_Type_List {
    pub data: Vec<(std::any::TypeId, &'static Cos_Job_Func)>,}

impl Cos_Type_List {
    pub fn into_registry(self) -> Cos_Type_Registry {
        Cos_Type_Registry::new(self)}

    pub fn push_item<T: Cos_Pure_Job_T + 'static>(&mut self) {
        self.data
            .push((TypeId::of::<T>(), &(do_work_wrapper::<T> as Cos_Job_Func)))}}

pub struct Cos_Type_Registry {
    type_id__to__func: HashMap<TypeId, &'static Cos_Job_Func>,
    type_id__to__u32: HashMap<TypeId, u32>,
    u32__to__type_id: HashMap<u32, TypeId>,}

impl Cos_Type_Registry {
    pub fn new(lst: Cos_Type_List) -> Cos_Type_Registry {
        let mut tids = lst.data.iter().map(|(tid, _)| *tid).collect::<Vec<_>>();
        tids.sort();
        let u32__to__type_id = (tids.iter().enumerate())
            .map(|(i, tid)| (i as u32, *tid))
            .collect::<_>();
        let type_id__to__u32: HashMap<TypeId, u32> = (tids.iter().enumerate())
            .map(|(i, tid)| (*tid, i as u32))
            .collect::<_>();
        assert_eq!(type_id__to__u32.len(), lst.data.len());
        Cos_Type_Registry {
            type_id__to__func: lst.data.iter().cloned().collect::<HashMap<_, _>>(),
            type_id__to__u32,
            u32__to__type_id,}}}

@H2CO3

Don't go around actively asking people, just in order to be able to call them wrong left and right, because that comes off as malice.

To the best of my knowledge, I do not need your permission t post here.

I think the core issue here is this: taking the sha256 sum of a u64 is pre-mature optimization / over-engineering / not the right solution to this problem. Out of respect for you, took the time to analyze your idea in detail, and instead of defending your idea, you resort to personal attacks.

[CAD97]

@Michael-F-Bryan

@scottmcm

There's one feasible way to get a u64 from a TypeId, though it's still subject to breaking on implementation changes:

You're assuming that TypeId's hash implementation is based on a single u64 (i.e. #[derive(Hash)] struct TypeId(u64)) so this isn't really any different from a transmute().

Honestly, I'd prefer if people just transmuted TypeId to u64 because it means readers will immediately see that you're doing something dodgy.

All currently proposed TypeId representations still provide a single u64 to Hash::hash. I think it is reasonable to guarantee this, and it's certainly better than a transmute, if write_bytes is implemented to panic.

What's properly dangerously unsound is the u64 -> TypeId direction. TypeId -> prehashed u64 is perfectly fine, because the absolutely worst that can happen is hash collisions, which you need to handle anyway. (i.e. do not implement your own unchecked downcasting based on the u64. Use TypeId comparison and/or checked Any::downcast_ref.)

[khionu]

A couple places this thread has gone wrong:

• Calling someone "offended" is implicitly invalidating their contribution because you assume (seriously or not) that they are getting emotional. This a terrible tactic that has no place anywhere. If you are knowingly offending people, pressing forward without a significant change in direction is one of the few ways that is never correct. Even if you don't think it's reasonable for people to have an emotional response to a thing, we're all human beings: emotions happen, and we should work together to find out why things have gotten off track.

• People are not obligated to accept advice. If you give people the best advice you can, it's on them what they do with it after that. If they harm themselves while ignoring your advice, that's that. You've done your part.

• If you are seeking advice on something you know is ill-advised, the burden of moderated response is on you. Next time, try framing it as minimally as possible, instead of throwing in all the details that you know people will object to.

I'm locking this thread as it's well over baked. Everyone, please reflect on what it means to consider the human on the other end, and think about the limitations of giving help over the internet.