Both are 3444 though. D might stand for draft, and indeed the copy on safecpp.org is labeled as a draft. So I guess it changed to a P when it stopped being a draft, and R0, idk, might mean revision 0?
IIRC we had the “Safe C++” before that adds rust to C++, incl. the lifetime annotations. That got critique in the C++ community with people claiming that those are unnecessary and too complex. This is the reaction to that critique.
For background: Sean did the Safe C++ proposal that includes all the life-time annotations rust has. This is a answer to critique that all that complexity is not needed. I read it as: You can indeed leave lifetime annotations out, but then you can do less.
I would say forget keeping around member references that are only used for destruction, such as in the ~lock_guard example. I see a more elegant solution:
Having resource-linear types opens up for destructors that take arguments, and when arguments have lifetime, this enforces correct destruction order more elegantly than requiring objects to carry around references to each other with lifetime annotations.
Being a linear (move-only) type means that instead of the compiler inserting an implicit destructor call at the end of the scope, compilation shall instead fail if the user failed to destroy an object of such type exactly once before the end of the scope. Then, instead of writing a destructor of a guard type that contains a reference to a mutex, you would write a normal function that takes the same mutex by reference and an empty move-only guard type by destructive move.
Was this not already posted? I’m confused, they have different “document numbers” but are the exact same article.
Both are 3444 though. D might stand for draft, and indeed the copy on safecpp.org is labeled as a draft. So I guess it changed to a P when it stopped being a draft, and R0, idk, might mean revision 0?
IIRC we had the “Safe C++” before that adds rust to C++, incl. the lifetime annotations. That got critique in the C++ community with people claiming that those are unnecessary and too complex. This is the reaction to that critique.
No, it’s literally the exact same paper you posted here 5 days ago, just on the WG21 website instead of on Sean Baxter’s website.
For background: Sean did the Safe C++ proposal that includes all the life-time annotations rust has. This is a answer to critique that all that complexity is not needed. I read it as: You can indeed leave lifetime annotations out, but then you can do less.
I would say forget keeping around member references that are only used for destruction, such as in the
~lock_guardexample. I see a more elegant solution:https://github.com/anordal/rustlike/blob/master/proposals/destructive%20move.md
Explanation:
Being a linear (move-only) type means that instead of the compiler inserting an implicit destructor call at the end of the scope, compilation shall instead fail if the user failed to destroy an object of such type exactly once before the end of the scope. Then, instead of writing a destructor of a guard type that contains a reference to a mutex, you would write a normal function that takes the same mutex by reference and an empty move-only guard type by destructive move.