Hacker News Reader

Comment by steveklabnik | Hacker News Reader

You're not wrong in general here, but C++ is going to get the core of reflection in C++26. I'm not sure enough of the details to know if it supports doing this, however.

Rust on the other hand... that might be ten years.

View on HN

There are various reflection crates available on crates.io, as you know.

Yeah, I always wished that the reflect crate got further along than it has.

I still think that language support us important, but unfortunately due to what happened, I suspect that will take a long time. And that’s disappointing.

We Bevy users use Rust reflection on a daily basis, and are very happy with it :)

I agree it'd be nice if it weren't confined to our community, though.

I should check it out, I haven't had an actual use-case for reflection lately, so I haven't given bevy_reflect a try yet, but when I do, I'll make sure to give it a shot.

How does it do reflection on third party types (non-Rust, non-Bevy types)? Those that don't derive Reflect?

Don't coherence rules prevent it?

Assuming by "non-Rust types" you mean "those that the bevy_reflect crate doesn't know about", it's indeed limited by the orphan rule. That being said, bevy_reflect offers many workarounds for this problem. Because bevy_reflect is based on a type registry containing function pointers, you can actually populate it manually for types external to your crate without using the Reflect trait at all if you want to. And if your type contains fields that aren't Reflect, then you can use custom reflection logic.

non-Rust meaning non-std types, for which Bevy reflect can do manual trait implementation.

Reply on news.ycombinator.com