Skip to content

Reflection and comptime goal #311

New issue

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

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

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Jun 6, 2025

With the renewed general interest in reflection via the facet crate coinciding with my own experiments with reflection, and some discussions with bevy folk at the all hands, I think that this may be a good time to pursue more language reflection capabilities than size_of and align_of.

Rendered

@fu5ha
Copy link

fu5ha commented Jun 7, 2025

Wanted to point out mirror-mirror as another prior art. We made it at Embark Studios for use in our Rust game engine. It's similar to Bevy reflect in many ways, with the most interesting differences being

  • An owned opaque Value type which can be interacted with thru the same reflection apis
  • key paths as a more ergonomic way to query thru layers of a reflected type

@lqd
Copy link
Member

lqd commented Jun 14, 2025

I've added a fix in #312 for the CI failure -- as well as fixed a bug in the template that would still prevent validation without the suggested changes below.


Creating new general purpose crates (like serialization crates, log/tracing crates, game engine state inspection crates) that should work with almost all other data structures is nontrivial today. You either need to locally implement your traits for other crates, or the other crates need to depend on you and implement your traits. This often hinders rollout and will never reach everything.

Reflection offers a way out of this dilemma, as you can write your logic for all types, by processing the type information at runtime (or even preprocess it at compile-time) without requiring trait bounds on your functions or trait impls anywhere.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love the sound of this, but I don't feel like I know exactly what use cases you are trying to enable or aiming to do. Can you give a bit more detail on what kind of things you aim to do? Is the (shiny future) goal to rewrite PartialEq and friends as some kind of fn that is written reflectively instead? Would it be generic over a data structure? Is the expectation that we could 'specialize" it to the type (and get efficiency)? Are you not sure yet, but you know the building block is X?

If you could give a high-level sketch of what these APIs might look like, that'd be great, and bonus points if you can sketch the whole set of connections you eventually imagine.

I don't want this goal to have everything designed up front or anything, I just want to understand the big pieces in your head.


## Design axioms

* Prefer procedural const-eval code over associated const based designs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there are interesting! I'm having a bit of trouble connecting them to the write-up above, perhaps because I don't quite get what alternatives you are weighing against.

|----------------------|------------------------------------|---------------------------------------------------------------------|
| Lang-team experiment | ![Team][] [lang], [libs] | Needs libstd data structures (lang items) to make the specialization data available |
| Author RFC | | Not at that stage in the next 6 months |
| Lang-team champion | ![Team][] [lang] | TBD |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tmandry would need to assign a champion here

| Task | Owner(s) or team(s) | Notes |
|----------------------|------------------------------------|---------------------------------------------------------------------|
| Lang-team experiment | ![Team][] [lang], [libs] | Needs libstd data structures (lang items) to make the specialization data available |
| Author RFC | | Not at that stage in the next 6 months |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| Author RFC | | Not at that stage in the next 6 months |

| Lang-team experiment | ![Team][] [lang], [libs] | Needs libstd data structures (lang items) to make the specialization data available |
| Author RFC | | Not at that stage in the next 6 months |
| Lang-team champion | ![Team][] [lang] | TBD |
| RFC decision | | Not at that stage in the next 6 months |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| RFC decision | | Not at that stage in the next 6 months |

| Design meeting | ![Team][] [lang] | |
| Author call for testing blog post | | Likely will just experiment with bevy or facet, no general call for testing |

## Frequently asked questions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, some of the details I wanted are here, though I had some trouble understanding some of these questions. e.g., "why not go full zig-style comptime" in particular felt like a bit of a nonsequitor.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe because I don't know zig that well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants