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.
There was a problem hiding this comment.
seemed like the CI didn't like it, so I changed it back
| 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.
| 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?
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.
Yeah that matches my expectation (modulo the differing design idea of what directs the projection (field type vs field property)). I think we can model them using the field projection design that I currently have in mind (and also any other that I would consider useful). But this would require negative trait bounds & that compiler allows you to implement a trait for T: !Unpin & T: Unpin differently.
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?
I have one problem in mind when making all Deref types implement Project: at the moment, you can implement projections on &Concrete (so eg &mut MaybeUninit<T>). And that is pretty useful for container types & we would like to do that for custom types in RfL too (and our type is not a simple container one, so if we just special case them it probably won't work). So that might be a bigger blocker. Otherwise I haven't given the question a lot of thought, so we should definitely talk about it in the design meeting(s).
|
|
||
| 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.
There was a problem hiding this comment.
indeed, though they already are much more ergonomic than NonNull<T> today. But they would also look much more like references do today (with a different sigil of course).
|
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.