https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2024-03-25
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #2)
> (In reply to comment #1)
> > Unless I'm misunderstanding your suggestion I think that a compiler is not
> > allowed to apply copy-elision here, because that case was explicitly
> > excluded
> > from 12.8 p31 by
> >
> > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1148
>
> Really? Apart from the fact that no compiler implements it so it probably
> didn't look like a huge sacrifice at the time, it is in my opinion moving in
> the wrong direction (less elision, when we actually need a lot more).
There have been a lot of changes in the area of copy elision in recent
standards (see links below) but the "other than a function parameter" wording
still remains. So I don't think we can make this optimization without a change
to the standard.
What we are allowed (and even required) to do is treat return values as rvalues
more often, and so perform moves instead of copies. Even if we can't elide that
move entirely, it's better than a copy.
Is it worth keeping this open if we're not allowed to make this change?
Guaranteed copy elision:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html
Implicitly move from rvalue references in return statements / More implicit
moves:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html
Simpler implicit move:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2266r3.html
