Pre-RFC: Partial Initialization and Write Pointers

[GolDDranks]

I think @newpavlov’s suggestion is a lot nicer as it seems generally simpler and less ad-hoc.

We could allow safely coercing &out T safely to &mut T in the occasion &out T is successfully written to, but the mechanism to ensure that sounds hard to come by, especially if it requires reasoning about partiality. Similar to Pin, just providing an unsafe interface for now seems like good enough for getting started with the feature.

[gbutler]

This way we will get “read-only” ( &T ), “read-write” ( &mut T ) and “write-only” ( &out T ) references,

Ah, yes, neat. Could &out T also be used to represent write-only memory buffers (like for example that are needed for OpenGL types of things in some cases)? For example, there are some low-level video buffer API’s where the buffer is write-only and if you attempt to read it, it causes a page-fault/segmentation-violation from the kernel. Could &out u8[]slices be used to represent that for example?

[newpavlov]

Could &out [u8] slices be used to represent that for example?

Yes, absolutely!

[gbutler]

Perhaps two different types of references would be most useful:

• &out T is a write-only reference to a !drop type
• &uninit T is a write-once, then readable reference to any type

&out T borrowing rules would be that you could have any number of &out T references simultaneously, but, no concurrent &mut T or &T references only have a single &out T reference in effect, the same as &mut T. &uninit T would have the same borrowing rules as &mut T and you could not have an &uninit T concurrent with an &mut T.

Once fully initialized you could coerce an &uninit T to an &mut T or an &T. A !drop &uninit T could be coerced at any time to an &out T. A drop &uninit T could not be coerced to a &out T. You could never coerce an &mut T to an &uninit T.

So, we would then have 4 reference types:

• &T - that we all know and love (read-only, multiple-concurrent)
• &mut T - that we all know and love (read/write, exclusive)
• &out T - (write-only, multiple-concurrent, !drop only types)
• &uninit T - (write-once, then read, exclusive, drop|!drop types)

Valid coercions would be:

• &T (none)
• &mut T -> &T or &out T
• &out T -> &T or &mut T (no, this would be unsafe)
• &uninit T -> &T or &mut T once fully initialized (until then, may not be coerced) or -> &out T if it is a !drop type (at any time)

Caveat: Allowing coercions from/to &mut T and &T for &out T kind of defeats the real benefit of &out T (being write-only memory). So, it would be nice to NOT allow that so the coercions (safe coercions that is) would be:

• &T (none)
• &mut T -> &T or &out T
• &out T (none, once an out always an out)
• &uninit T -> &T or &mut T once fully initialized (until then, may not be coerced) OR to &out T if it is a !drop type (at any time)

It seems like having both a new &out T and a new &uninit T would be useful for different orthogonal purposes. &out T would be especially useful for things like write-only video buffers or other type of specially mapped pages. &uninit T would be useful for in-place initialization without copy/move.

[Soni]

if you have a struct with multiple fields, can you pass an write pointer to its subfields, for initialization? or do you need to pass an write pointer to the whole thing?

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