I think this should go into a separate issue.

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.

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.

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

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

AFAIU you don'treassign a value to a variable moved away. Youbind 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.

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.

I think we're talking past each other. Are you referring to variables implementingCopy? Then I agree with you. But OBRM-Objects do, virtually by definition, implementDrop and thus notCopy.

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.

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

structMoveSemantics{field:String,}structWhateverElse(u32);fnmain(){letmut to_move_out_of =MoveSemantics{field:String::from("Whatever"),};// move value out of to_move_out_of,// afterwards its illegal to accesslet moved_to = to_move_out_of;// errorlet 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 memorylet to_move_out_of =WhateverElse(2);}

I think I used the right terminology here, thevariable is the name and refers to the memory, thevalue 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.

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.

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

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

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.

This paragraph is not exactly wrong, but an imo important thing to understand when working with C++ is that the rulesin the language are actually notthat 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.

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.

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

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?

No, I think your change is perfectly fine.

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

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.

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.

Yes, that would also be fine.

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

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 callClone::clone).

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.