How about when passing across function boundaries. Also, upon first write we will promote a &write T
to &mut T
, so it will have that behavior locally.
That seems interesting, and that could work.
You can pass a write pointer to itâs sub-fields
Also, on the note of the caveat, not only does it defeat the purpose, it is unsafe to coerce &out T
or &uninit
to &T
or &mut T
, for the same reason it is unsafe to coerce &T
to &mut T
. You are adding behavior that was thought to be impossible. Either a read ability or a write ability.
Yes, I agree. I'm not sure why I even mentioned it as a possibility.
I havenât used any write only buffers, or anything that needs a &out T
as it is defined here, so I donât know what sort of examples are relevant, any help with examples are welcome.
Also thank you all for the help in refining this Pre-RFC, I have learned a lot about write only pointers through this. I will post this as an RFC tomorrow barring any large changes to the Pre-RFC.
This has been a great first RFC experience for me.
Mainly specialized memory pages allocated for HW interfaces, primarily video output related. For example, for security reasons, you may want to allow writing to a framebuffer but not reading from it. This can be controlled by the OS allocating a write-only page and returning it to the application. If the application attempts to read from the page, it causes a page fault and the application is killed. You may want to represent something like that in Rust as an &out T[]
because you want to statically ensure that the program never attempts to read from that memory (including trying to move it, so &out T
would imply Pinned as well).
Ok, that makes sense, thanks for the info. Iâll see if I can make an small example related to that.
Note that the correct restriction is not !Drop
but that the type has no drop glue.
what if making a write-once pointer to an initialized struct/etc causes Drop, but uninitialized doesnât?
with MaybeUninitialized etc youâd just need a method/intrinsic or something that creates the write-once pointer?
Note that the correct restriction is not
!Drop
but that the type has no drop glue.
What do you mean by no drop glue? That none of the fields are Drop? (and none of the fields on those fields are Drop, and so on recursively).
what if making a write-once pointer to an initialized struct/etc causes Drop
No this won't work, because creating a pointer, shouldn't do anything on it's own, but get an address. Otherwise, it would lead to subtle and easy to miss bugs.
creating a must-write-once pointer would cause deinitialization.
that way, &write would always support (and require) writing exactly once, regardless of Drop or lack thereof. i.e. it would be safe.
Just because it is safe, does not mean it canât be confusing. I want to limit the confusion it would cause to have subtle side-effects when creating a reference. Also, this proposal has changed significantly, due to gbutlerâs post a few days ago.
The new proposal now splits &write
into &out
and &uninit
. Which serve two orthogonal purposes.
Now &uninit
serves a similar purpose to what you are suggesting, at least for uninitialized values.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.