Switch from RAII to OBRM Terms, expand and improve parts (#322)

[9SMTM6]

This attempts to solve #322.

Since what was to be done finally was still up for discussion I've now mostly followed by opinion, and have not accounted for that of others.

This obviously isnt entirely finished and still needs polishing, but should serve as a basis for discussion.

[9SMTM6]

markdownlint doesnt seem to have an autofix for the line-lenght lint.

As long as we're still discussing the changes I won't put in the work to manually fix these lints, housekeeping that result manually during subsequent changes is frankly no use of my time I accept.

[9SMTM6]

Also, I should note that I dont have a TERRIBLE lot of experience with RAII in C++, so these sections are more at risk of being slightly wrong or not as complete as one could wish.

[simonsan]

I think this should go into a separate issue.

[9SMTM6]

Yeah, I just noticed that while I was there, and didn't have time nor was sure how to approach that. But a seperate issue for that is totally fine by me.

[neithernut]

Some comments from my side. I actually only have some minor nits about the content. Most of my ramblings are more motivated by @9SMTM6 expressing not being too familiar with C++.

[neithernut]

I'd highlight the "O" in "OBRM" a bit more: the object "owns" the resource and thus is responsible for releasing it. But that may be personal preference.

[neithernut]

In the sections above you say "ORBM-Object". I'd stick to that one.

[9SMTM6]

It was some sort of attempt of not having to rewrite sections below, and also of introducing the guard terminology which is also used in rusts stdlib (eg with the mutex guard).

[neithernut]

AFAIU you don't reassign a value to a variable moved away. You bind something new to a name which now happens to be unused. One consequence is that the new thing doesn't need to have the same type.

Also, I'd split this sentence into two, e.g.

Suggested change

	In Rust, a moved-out-of variable can not be used, only reassigned a new value (this is referred to as "destructive move"), and the behavior on a move is not customizable, instead a move simply copies the bytes of the moved-out value into the moved-into variable, and ensures the semantics of a destructive move.
	In Rust, a moved-out-of variable can not be used (this is referred to as "destructive move"), though the name of that variable can be re-used.
	The behavior on a move is not customizable, instead a move simply copies the bytes of the moved-out value into the moved-into variable, and ensures the semantics of a destructive move.

[9SMTM6]

AFAIU you don't reassign a value to a variable moved away. You bind something new to a name which now happens to be unused. One consequence is that the new thing doesn't need to have the same type.

I'm pretty sure you can and I have reused a variable that was moved out. In that case it has to have the same type, and it'll use the same memory, which is the purpose of that rule (and probably the reason C++ requires that an object still be usable after being moved out of), rust found a somewhat more elegant way.

If you want to reuse the name only yeah you can vcreate a new let binding shadowing the variable, but thats not what I'm referring to.

But perhaps thats a sign that should be made more explicit?

Otherwise splitting the sentence is a good suggestion.

[neithernut]

I think we're talking past each other. Are you referring to variables implementing Copy? Then I agree with you. But OBRM-Objects do, virtually by definition, implement Drop and thus not Copy.

I thought you meant creating a new binding using the same name. In this case you may end-up reusing the memory previously occupied by the moved value, but that being specified in the language would be news to me.

[9SMTM6]

Yes we probably are. Heres some code to ensure we understand each other now:

struct MoveSemantics {
    field: String,
}

struct WhateverElse(u32);

fn main() {
    let mut to_move_out_of = MoveSemantics {
        field: String::from("Whatever"),
    };
    // move value out of to_move_out_of,
    // afterwards its illegal to access
    let moved_to = to_move_out_of;
    // error
    let attempt_access = to_move_out_of.field;
    // reassignment to variable is legal and uses the same memory 
    // (not for the string, which is a seperate allocation, but even if 
    // to_move_out_of would be on the heap it would be reused nonetheless AFAIK
    // this might be beneficial for some situations
    // needs to be the same type of course
    to_move_out_of = MoveSemantics {
        field: String::new(),
    };
    // shadowing of the variable name, doesnt use the same memory
    let to_move_out_of = WhateverElse(2);
}

I think I used the right terminology here, the variable is the name and refers to the memory, the value is whats written in the memory and abstractly also connected resources, and you can define a new variable which has the same name as a old one, which would be what you've described above as far as I understood it.

[9SMTM6]

I was referring to the reassignment of the variable.

The reason I felt the need to mention that possibility is that its the one "usage" of the variable that is allowed, AFAIK all others are forbidden. So for completeness its required unless we find another formulation that covers only "usages" of a variable other than reassignment. Also some C++ programmers might be looking for something like that, and might otherwise wrongly think you cant do it.

We could say thats not worth the effort and strike it, or we expand on it, or we keep it as-is and hope people understand it correctly.

[neithernut]

Just as I thought, I misinterpreted what you wrote. I think we're on the same page now.
The only case where you can reuse a variable after passing it by value is if its type implements Copy, so maybe the following would work?

Suggested change

	In Rust, a moved-out-of variable can not be used, only reassigned a new value (this is referred to as "destructive move"), and the behavior on a move is not customizable, instead a move simply copies the bytes of the moved-out value into the moved-into variable, and ensures the semantics of a destructive move.
	In Rust, a moved-out-of variable can not be used (this is referred to as "destructive move") unless its type implements [Copy].
	The behavior on a move is not customizable, instead a move simply copies the bytes of the moved-out value into the moved-into variable, and ensures the semantics of a destructive move.

The hint at Copy should be sufficient imo. C++ people new to rust will probably look it up.

[simonsan]

C++ people new to rust will probably look it up.

Please keep in mind that this book is not aimed at only either C++ developers or experienced programmers. We want to try to keep it as inclusive as possible, also to newcomers from other languages. I say that, because if there is a term, that C++ developers need to look up, it's probably good to at least try to explain it a bit or use a less complex explanation/go less into detail.

I haven't had much time the last days to review more of this article, but it's good that others did and you together keep on working on it. I will probably manage to read over it (in terms of reviewing) beginning of next week.

[neithernut]

This paragraph is not exactly wrong, but an imo important thing to understand when working with C++ is that the rules in the language are actually not that incredibly complex when it comes to object lifetimes. But they are from another era, and the choices back then had some unfortunate consequences, some of which you detail on further down.
Also, the whole "move" in C++ is really more a convention rather than a concept that exists in the language. And so you end up with zombie objects which end up in an "undefined-but-recoverable" state (simplified for educational purposes) after their contents was moved to another instance.

[9SMTM6]

You are correct, the rules are not really that complex. What is complex is executing it.

As you say, because moves are more of a convention in C++, which more or less mostly just added a move operation and let the developers implement it, you get undefined states for many objects even in the standard lib, with a few exceptions where behavior is defined in the standard, like unique_ptr AFAIK.

[neithernut]

Not exactly sure but I think even for unique_ptr the standard doesn't mandate that the object moved from is in a defined state but only that a call to std::unique_ptr::reset() will transition it to a defined state. But I imagine any sane implementation will leave a moved-from std::unique_ptr in a reset-state, already.

[9SMTM6]

We are getting a bit sidetracked;-P.

I could rewrite that section to say something to the nature of "copy and move in C++ are just operations with connected conventions, which must be upheld across the respective copy (assignment) constructor and move (assignment) constructor and might also need adjustments to the destructor", which AFAIK would be the correct description but seems fairly complex right now, and more importantly, AFAIK isnt really how people usually think about copy and move.

Other suggestions, or do you think that suggestion is fine?

[neithernut]

No, I think your change is perfectly fine.

[neithernut]

... and thus is more comparable to an Option<Box>, but less safe.

[9SMTM6]

In terms of how its working under the hood if used correctly, yes. But many people work under the assumtion that unique_ptr will always or at least mostly not contain nullptr.

I'm not certain how to express that without overcomplications, and in the end, unique_ptr was introduced with similar aims to box, so I kept it simple at the expense of being perhapos not entirely correct.

[9SMTM6]

We could fix the correctness though, by not saying unique_ptr is equivalent, but instead something like that it was introduced for the same purpose.

[neithernut]

Yes, that would also be fine.

[9SMTM6]

Rewrote it, but perhaps you can think of a more fluent way to express it. Otherwise feel free to resolve this.

[neithernut]

You more or less captured already this already:
In C++, objects are expected to stay where they are (in memory) but you end up copying objects every now and then (and knowing when its acceptable is important for a C++ dev). Forbidding that is often an explicit choice and moving is also often more explicit.
In Rust, values tend to move around and if they are simple enough (like a Plain Old Datatype in C/C++), they can impl Copy. If they are not you have to impl Clone in order to multiply an instance, and cloning is always explicit (you have to call Clone::clone).

[9SMTM6]

I believe if we address the points above we might integrate this with the section above about (currently) "complex C++ rules", but as it is this section still holds new information as far as I can see.

I'd defer this until we've cleared up the parts above.

[simonsan]

Any updates on this? 🚀