-
Notifications
You must be signed in to change notification settings - Fork 58
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
base: main
Are you sure you want to change the base?
Conversation
Wanted to point out
|
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 | |
There was a problem hiding this comment.
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 | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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 | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
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 thansize_of
andalign_of
.Rendered