[WIP, Pre-RFC] statics inside <...> and fixing unsoundness bugs

[Soni]

This is a lot better than macros:

• Generic type inference actually works.
• Cleanly propagates to generic callers.
• Backwards compatible.
• Can you even make function pointers to generic functions? I never tried tbh.

[retep998]

Can you even make function pointers to generic functions? I never tried tbh.

Yes, you can have function pointers to monomorphizations of a generic function.

[Soni]

how does that work?

yes, you can have pointers to monomorphizations of these.

[matt1985]

• Generic type inference actually works.
• Backwards compatible.

How do these not apply to macros?(It’s not obvious what you are talking about here.)

• Cleanly propagates to generic callers.

I would not call propagating statics to the caller clean. At least with macros you can tell something weird might be happening.

Also,as one of the alternatives you should mention passing down a &'static Foo instead of a generic static,and say why that does not work.

[Soni]

let x: &Foo = any.downcast_ref();
let x: &Foo = downcast_ref!(any); // doesn't work, no way to get/use &Foo from inside the macro

[matt1985]

Your specific macro is wrong.

[Soni]

how? it clearly shows the lack of type inference…

[matt1985]

In you macro specifically,not Rust in general.See vec in the standard library.

[Soni]

okay, do you think you can convert the two macros of eventbus to remove the need of explicitly passing in the type?

[matt1985]

Maybe,I haven’t seen them yet.And even I looked at them,I would have to know what you want them to be like(beyond not passing the type).

[Soni]

the eventbus logic is that you’re likely to have a lot of events, but only one or two busses (or, at least, a small amount of them). we also want all accesses to be simple offsetting (vec indexing).

(side-note: I actually had no idea Any was fast when I was making the thing, but once I found out I didn’t finish the optimizations. in fact, one of the alternatives is to just make Any painfully slow and my code will still work just fine and fast if I finish those optimizations.)

this means I need to convert slow AnyMap/T to a fast (monotonically assigned) usize. this needs to be stored in the caller, because we can’t have generic statics (static FOO<T>: Foo<T> = FOO_INIT;). - in fact, generic statics would also solve the TypeId problem, as mentioned in the original issue. this is exactly what makes these problems so similar, and is exactly what’s being worked around by my proposal.

anyway, once we have the usize, we can just skip the slow lookups and do a fast lookup.

[matt1985]

Having tried this locally,I was able to get register_hook working without having to specify the event type.

However,with post event,I was unable to get it working because there is no way it could infer that you want to coerce from &mut dyn_events::MyEventImpl to &mut dyn dyn_events::MyEvent.

I can see why you want to have trait reflection(given your design) now that I tried this change locally.

I will do a pull request later tonight,after figuring how to use the platform you are hosting the repository on,then we can continue the discussion on this over there in the pull request.

[Soni]

if you remove the static DUMMY then you’re doing it wrong. statics can’t be generic, so I’m using that specifically to disallow

fn foo<T, F: Fn(&mut T)>(f: F) {
register_hook!(bus, T, f); // currently disallowed because T is generic
}

because if you could do this, then you’d be using the wrong (same) event ID for different event types.

[matt1985]

because if you could do this, then you’d be using the wrong (same) event ID for different event types.

Ok then,with that constraint,the changes I made won’t work.

I don’t think I can help you here,because I would have rewrite your crate from scratch(I don’t want to do that).

[Soni]

I’ve rewritten it from scratch like 20 times (not all of those have been published). This is what I’m most comfortable with, as it’s the closest to generic statics I can get.

Since Any runs into the exact same issue as me, I feel like it’s fitting to do any of these, where the first three are backwards-incompatible and the latter three are backwards-compatible:

• Get rid of Any.
• Get rid of Windows.
• Reimplement Any a la my crate.
• Make Any special (this exact proposal but without language changes).
• Add statics inside <…> to the language, reimplement Any with it.
• Make Any and eventbus so slow to the point of making them useless. (I feel this goes against the Rust motto “Rust […] runs blazingly fast, […]” (from the homepage))

[matt1985]

Make Any and eventbus so slow to the point of making them useless. (I feel this goes against the Rust motto “ Rust […] runs blazingly fast, […]”

Static generics

" Rust is a systems programming language that runs blazingly fast, […] " - rust-lang.org

(* unless you’re trying to write high-performance code in 100% safe rust.)

Stop with that.There is no need to say that Rust fails if your design is slow.

[Soni]

Rust fails if Rust is slow.

including Any.

[matt1985]

It’s your code that is slow. People are perfectly capable of making fast Rust code.

BTW saying Any is slow is not saying that Rust failed.Certain abstractions are just inherently slower than other,and making them work fast requires effort.

[Soni]

It would be Any that’s slow, if you stick the whole type ID into the TypeId, rather than just the hash.

Well, sticking the whole type ID into it doesn’t necessarily make it slow, but if you compare it slowly, then it will be slow. And we can avoid that, if we choose to make a relatively simple language change.

My proposal is zero-cost: you don’t pay binary size if you don’t use Any/it. But the main benefit of my proposal is making Any sound while maintaining performance.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.