Propose goal: Field Projections #329
Conversation
src/2025h2/field-projections.md
Outdated
| | Task | Owner(s) or team(s) | Notes | | ||
| |----------------------|-------------------------------------|---------------------------------------------------------------------| | ||
| | Design meeting | ![Team][] [lang] | Possibly more than one required as well as discussions on zulip. | | ||
| | Lang-team experiment | @dingxiangfei2009, @BennoLossin, ![Team][] [lang] | | |
There was a problem hiding this comment.
I'm not sure exactly what @nikomatsakis envisioned here when implementing the checks, but this will fail CI tooling as it will think you two are also teams. Likely this check should be improved on our side ^^. cc @tomassedovic
There was a problem hiding this comment.
I can move us to the notes section if that's the intended location
There was a problem hiding this comment.
I'd say move to notes for now then.
There was a problem hiding this comment.
done, also did this for the "Author RFC" part, let me know if that's wrong.
| Additionally, Rust for Linux could take advantage of field information present in the current | ||
| proposal. Essentially answering the question "does this type have a field of type X at offset Y?" | ||
| via traits. |
There was a problem hiding this comment.
Can you take a look at #311 for this and let me know your thoughts? Do you think we can unify the proposals?
There was a problem hiding this comment.
I read through the goal, but didn't understand what exactly the solution is going to be (which is probably because nobody knows that :) so I can't say for sure that it will cover our use-case.
Our use-case is something that would be covered by reflection as I would understand it. One of our use-cases is detecting if a field of a struct is a specific type (for the details see here).
The current idea for field projection will still have field traits, so it would enable using traits for field inspection. We might want to do something different, but I don't know how that would look like.
src/2025h2/field-projections.md
Outdated
| | Task | Owner(s) or team(s) | Notes | | ||
| |----------------------|-------------------------------------|---------------------------------------------------------------------| | ||
| | Design meeting | ![Team][] [lang] | Possibly more than one required as well as discussions on zulip. | | ||
| | Lang-team experiment | @dingxiangfei2009, @BennoLossin, ![Team][] [lang] | | |
There was a problem hiding this comment.
I'd say move to notes for now then.
| Figure out the best design for field projections. Update the existing [Field Projections RFC] or | ||
| author a new one and implement it for use in nightly via a lang experiment. | ||
|
|
||
| [Field Projections RFC]: https://github.com/rust-lang/rfcs/pull/3735 |
There was a problem hiding this comment.
It seems like the thinking has progressed since this RFC, in which case I encourage you to also link the latest draft.
| via traits. | ||
|
|
||
| Note that the projections listed above are also very important to Rust for Linux. Virtually all | ||
| types are pinned in the kernel, so `Pin<&mut T>` comes up a lot in drivers. We're also handling raw |
There was a problem hiding this comment.
Note that this is something we might add special syntax for, as part of pin ergonomics. See the design sketch at the top of rust-lang/rust#130494 (the third bullet in particular) and let me know if it matches your expectations.
It would be nice if we could describe both this and regular deref projection in terms of this more general feature. Though I can see there being downsides to that, if there are cases where sometimes you want to go through Deref and sometimes you want to project.. do any come to mind for you?
|
|
||
| Note that the projections listed above are also very important to Rust for Linux. Virtually all | ||
| types are pinned in the kernel, so `Pin<&mut T>` comes up a lot in drivers. We're also handling raw | ||
| pointers very often where we could use `NonNull<T>` instead if they had better field access. |
There was a problem hiding this comment.
Maybe raw pointers would benefit from the syntax too.
|
Other than the comments I think this looks reasonable to merge. |
Rendered
I made this rather brief, so let me know if the motivational sections need to be expanded.
Some blanks (eg task owners) still need to be filled in, since I didn't know what to put there, just let me know.