Pre-RFC: Partial Initialization and Write Pointers

[Yato]

This seems nice, but I would like to be able to use this feature without using unsafe code, also this doesn’t solve the problem of expensive moves, (when you call buffer.into_inner() you move a potentially large object around). Also, I would like to allow Drop types and a number of rules are there so that Drop types are safe, and not confusing.

This is a fairly advanced feature, and goes into the realm of micro-optimization, and is in general not needed. But in the cases that it is needed, it would be good to have Drop types, to be able to directly initialize into the allocated memory and to be completely unsafe free.

But I do want to note, we don’t have to be completely safe around Drop types, because Rust does not guarantee that destructors run, we even have a type ManuallyDrop, and a function forget that explicitly allows you to not run destructors. This would just be really confusing to new people, so everything related to drop types in this rationale can just be lints that are error-by-default.

Rationale for Rules

&write T can only be assigned to once
This rule prevents unintended writes and allows for Drop types to be used safely, without fear of memory leaks.

After being written to &write T are promoted to a &mut T
This is mostly just ergonomics, to allow free usage of the value we just created.

Writing does not drop old value.
This is necessary for handling uninitialized memory. Note the semantics are different from &mut T, so it would cause confusing bugs to allow this coercion if Drop types are allowed.

You can only reference partially initialized memory through a &write T
This is also to ensure that uninitialized memory does not get read from.

&write T follows the same rules as &mut T for the borrow This note is so we have a xor relation between many reads and one write, to ensure memory safety, for the same reasons as &mut T

If you access fields of T using a &write T

• T: !Drop , this is only initially to ease of implementation (don’t have to worry about drops)
• This restriction could be removed
  This is just in-case there was some unsoundness with &write pointers to Drop types

You cannot conditionally assign to a &write T
This removes the need for unsafe code.

Functions and closures that take a &write T argument must initialize before returning
This also ensures that we don’t need unsafe code, and prevents bugs where you take a &write reference, but you don’t need it.

&writeT cannot be coerced to and from another type
This would be confusing if drop types are allowed, otherwise, it is unnecessary

• You can take a &write T on any T
  Just a note, I don’t know if I need to say it, but I will.

[earthengine]

It will be a write-only reference, in other words you will not be able to dereference it, or get &T and &mut T in a safe code.

This is a big restriction! It almost destroy the main use cases of this feature: pass as function argument and expect the function to initialize it.

Writing does not drop old value. This is necessary for handling uninitialized memory. Note the semantics are different from &mut T , so it would cause confusing bugs to allow this coercion if Drop types are allowed.

Why not: &write T or &out T can only be uninitialized until first write. So the compiler will ensure there is no “old value” to drop. And the following:

let v: &out u32;
...
v=10;
v=20;

desugar to

let v: &out u32;
...
v=10;
let v = v as &mut u32; 
v=20;

[Ixrec]

This is a big restriction! It almost destroy the main use cases of this feature: pass as function argument and expect the function to initialize it.

I’m not following this. Why would initializing a value behind a reference require dereferencing it or converting it to & or &mut?

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