Reflection and comptime goal #311
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.
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.
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.
@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.
| | 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.
| | 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.
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.
maybe because I don't know zig that well
|
|
||
| * Prefer procedural const-eval code over associated const based designs | ||
| * We picked `const fn` in general evaluation over associated const based designs that are equally expressive but are essentially a DSL | ||
| * Ensure privacy is upheld, modulo things like `size_of` exposing whether new private fields have been added |
There was a problem hiding this comment.
How will privacy be enforced? E.g. for serialization, it is important that private fields can be accessed in serde code. At the moment the privacy boundary is natural as the proc-macro generated code is inside the same module as the struct etc. Would it be possible to give serde access to some private fields, but not other random reflection code? Or is the idea that anything exposed to reflection should be the equivalent of a pub struct with pub fields, and any e.g. deserialisation validation would need to be pushed into a later conversion to a different type? Perhaps we'll need some #[reflect] macro to annotate some fields, though that would open a can of worms of which modifiers from serde and elsewhere to support.
With the renewed general interest in reflection via the
facetcrate 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_ofandalign_of.Rendered