[DRAFT] RFC: Gradual struct initialization

[Centril]

Rendered

This is a draft version of an RFC for you to review, before a formal proposal is made for consideration.

r? @pnkfelix @nikomatsakis -- I have left some TODOs for you to fill in... :)

---

note to self: squash the commits before publishing!

[Centril]

Some work TODO!

[Centril]

cc @pnkfelix & @nikomatsakis

[Centril]

cc @pnkfelix & @nikomatsakis

[Centril]

cc @pnkfelix & @nikomatsakis

[Centril]

@pnkfelix & @nikomatsakis: also please review this section so that it makes sense to you and reflects the guide section / or if not let's make it do so...

[Centril]

cc @RalfJung so I "get a place in the queue of stuff" Ralf has to review. =P

[RalfJung]

I think the RFC should explain what is old behavior, what is making behavior consistent with a similar case and what is really new. For example, nothing in "Definitive initialization and usage" is new AFAIK, this is already how we treat local variables (when they are not fields).

Basically, most of this RFC makes it so that fields of a struct behave even more like local variables behave already. That's great, I think we should do that! It should be clear which part goes beyond that, if any. Conversely, the normative text of the RFC should apply to struct fields and locals alike, to make it clear that behavior is consistent after this RFC gets accepted.

The part that (seems to me) goes beyond this is the part about self-referential structs. Is that really as simple as the RFC makes it sound? Will this require dedicated support in NLL or so, or does it just fall out of everything else?

---

Should we allow gradual initialization for types implementing Drop?

While this might make the language more consistent and uniform, [...]

Actually I'd argue it does the opposite: We already cannot move out of fields of a Drop struct, and hence it is just consistent that we also cannot partially initialize "into" such a struct. Basically, structs which implement Drop are always fully nor not-at-all initialized. I think that makes a lot of sense.

Since this concerns code that is automatically inserted by the compiler (drop glue), which can already sometimes be hard to reason about, I'd say let us be careful here and not make this any more complicated than it already is.

[Centril]

I think the RFC should explain what is old behavior, what is making behavior consistent with a similar case and what is really new. For example, nothing in "Definitive initialization and usage" is new AFAIK, this is already how we treat local variables (when they are not fields).

Will do.

Basically, most of this RFC makes it so that fields of a struct behave even more like local variables behave already. That's great, I think we should do that! It should be clear which part goes beyond that, if any. Conversely, the normative text of the RFC should apply to struct fields and locals alike, to make it clear that behavior is consistent after this RFC gets accepted.

I'll try to make this clearer. :) Should be fairly easy as the self referential struct bits are somewhat separate textually.

The part that (seems to me) goes beyond this is the part about self-referential structs. Is that really as simple as the RFC makes it sound? Will this require dedicated support in NLL or so, or does it just fall out of everything else?

I could be wrong but it seems to me that it is really mostly a syntactic restriction that is being lifted and that NLL/polonius already supports this, but I could be wrong! This seems like an excellent bit for @pnkfelix and @nikomatsakis to elaborate upon and fill in in the RFC. =P

Should we allow gradual initialization for types implementing Drop?
While this might make the language more consistent and uniform, [...]

Actually I'd argue it does the opposite: We already cannot move out of fields of a Drop struct, and hence it is just consistent that we also cannot partially initialize "into" such a struct. Basically, structs which implement Drop are always fully nor not-at-all initialized. I think that makes a lot of sense.

Right so the idea is that restrictions around Drop are somewhat arbitrary restrictions; it would be more consistent to not have such restrictions and then everything would be net more consistent. However, if we don't allow you to move out of fields of a Drop struct then we should probably not permit gradual init for Drop structs either; they are inexorably linked.

I would be glad to integrate any textual changes you propose that improves on nuance here.
I'm not sure how to improve it myself at the moment tho.

[RalfJung]

Right so the idea is that restrictions around Drop are somewhat arbitrary restrictions; it would be more consistent to not have such restrictions and then everything would be net more consistent. However, if we don't allow you to move out of fields of a Drop struct then we should probably not permit gradual init for Drop structs either; they are inexorably linked.

I would be glad to integrate any textual changes you propose that improves on nuance here.
I'm not sure how to improve it myself at the moment tho.

I'd just add a sentence when Drop comes up that not permitting partial initialization on impl Drop types is consistent with not allowing moving out of them: The compiler ensures they are either fully initialized or not at all, to avoid any ambiguity about whether the destructor runs or not.

[Nadrieril]

I just stumbled upon this beautiful RFC. It feels like a natural extension of existing features, shall we resuscitate it?

[Centril]

@Nadrieril Feel free to finish the draft :)