Thank you both for your comments.
> I'd very much like to see sections on the comparisons with the
various papers that came in the past. It'll both show you're aware of
all the historical context as an author, and save the readers the
trouble of having to think through all of it when reviewing.
I will work on it. Thank you for pointing out the proposals on the same topic, I find it hard to search for them. Is there some central place I'm missing? I only found http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
but it's not convenient to browse through all of them. Likewise, you mentioned this section should also "answer to the previously surfaced objections"; but do you know how I find them?
Watch my C++Now 2019 talk, "Trivially Relocatable," which includes a survey of the previous approaches and a few "adjacent" proposals/notions.
I will also get in touch with Arthur O'Dwyer and Howard Hinnant. I see Arthur O'Dwyer is the author of one of the linked proposals but has Howard Hinnant worked on something similar?
Yes, move semantics; although I don't know that he'll have anything super exciting to convey in this decade that hasn't been assimilated into the previous decade's literature already. (No offense, Howard! Just trying to save you some work. ;))
Pablo Halpern was the original "destructive move" proposal guy; I talked with him extensively during the formative year of P1144 "Trivially Relocatable." The C++Now talk covers some differences between his version and mine. See also
and in fact all of
Niall Douglas (at one point) had a proposal P1029 in the area; see the C++Now talk for more on that. Niall's proposal was adjacent to Herbceptions; you should study whether your proposal has any application to Herbceptions.
Finally, Denis Bider made another "outsider proposal" back in 2016 with a superficially similar idea of inventing a new sigil and making a special constructor that takes that-sigilled kind of references. (Also, using `>>` instead of `reloc`.) You should study that proposal in particular, because it kind of smells like yours might be isomorphic to it?
However, having a dedicated constructor for relocation allows for more freedom in the relocation implementation. In what I propose, the relocation constructor can be more than a memcpy, if needs be. I don't know if there are cases where relocation involves more than a memcpy, but it might (instance tracking?).
Your proposal seems to depend on the compiler to implement dataflow analysis in the front-end, similar to Herb's in/out/inout parameter proposal. Right now, C++ scrupulously avoids forcing the compiler front-end to do dataflow analysis or really any kind of non-local reasoning (with a few very ancient exceptions, such as forward references to members). This is basically Gasper's objection.
P2025 is related, in that I believe it forces a certain amount of dataflow analysis, and maybe if it got in then you could piggyback on its analysis, somehow. Look into that.
Status quo, though, I would characterize the need for dataflow analysis as a killing flaw for the entire proposal. Dataflow analysis is to be avoided inside a single scope, but it definitely can't be done across several function scopes. So dataflow analysis kills refactoring. (Of course, C++20 introduced coroutines with the exact same flaws re compiler complexity and refactoring, so maybe you can piggyback on that terrible precedent.)
I'll try to review your paper more in depth sometime (maybe not until next week though)... and may answer in the form of a blog post. I'm pretty sure my take will be "This doesn't work," but I'm not sure yet whether my take is "This has flaws that are a superset of P1144's," or merely "This has flaws different from P1144's."