Propose goal: Field Projections #329
Conversation
| | 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.
| 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?
| | 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.