Date: Tue, 1 Feb 2022 11:54:39 -0500
On Tue, Feb 1, 2022 at 11:10 AM Sébastien Bini via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Hello again,
>
> Thank you both for your comments.
>
> @Gašper Ažman <gasper.azman_at_[hidden]> :
> > 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.
https://www.youtube.com/watch?v=SGdfPextuAU
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
https://quuxplusone.github.io/blog/2018/09/28/trivially-relocatable-vs-destructive-movable/
and in fact all of
https://quuxplusone.github.io/blog/tags/#relocatability
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?
http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0023r0.pdf
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?).
>
Read P1144!
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."
–Arthur
std-proposals_at_[hidden]> wrote:
> Hello again,
>
> Thank you both for your comments.
>
> @Gašper Ažman <gasper.azman_at_[hidden]> :
> > 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.
https://www.youtube.com/watch?v=SGdfPextuAU
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
https://quuxplusone.github.io/blog/2018/09/28/trivially-relocatable-vs-destructive-movable/
and in fact all of
https://quuxplusone.github.io/blog/tags/#relocatability
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?
http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0023r0.pdf
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?).
>
Read P1144!
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."
–Arthur
Received on 2022-02-01 16:54:51