Pre-RFC: Partial Initialization and Write Pointers

[Yato]

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.

[Yato]

That seems interesting, and that could work.

[Yato]

You can pass a write pointer to it’s sub-fields

[Yato]

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.

[gbutler]

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

Yes, I agree. I’m not sure why I even mentioned it as a possibility.

[Yato]

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.

[gbutler]

I haven’t used any write only buffers,

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).

[Yato]

Ok, that makes sense, thanks for the info. I’ll see if I can make an small example related to that.

[TechnoMancer]

Well, the right bound is !Drop ,

Note that the correct restriction is not !Drop but that the type has no drop glue.

[Soni]

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?

[Yato]

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.

[Soni]

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.

[Yato]

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.

[Yato]

I have submitted an RFC, so please continue the conversation here, thanks!

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.