Is removing necessity of std::move for local variables used for the last time a good proposal?

[Piotr Nycz]

Hello,

During discussion on SO
(http://stackoverflow.com/questions/23929800/is-stdmove-really-needed-on-initialization-list-of-constructor-for-heavy-membe)
I came to conclusion that necessity of using std::move for arguments
passed by value or local variables can be somehow relaxed for a
specific case where they are used for the last time - so its lifetime
is practically expired.

Some examples:

struct President {
std::string name;
President(std::string p_name)
: name(std::move(p_name))
// ^^^^^^^^^: MOVE or NOT TO MOVE?
{}
void setDefaultName()
{
std::string l_name = "XYZ";
name = std::move(l_name);
// ^^^^^^^^^: MOVE or NOT TO MOVE?
}
};

So, do you think is it a good idea to add a rule to C++ language that:

If the automatic variable is used as a source for copying and this is
the last time variable is used - then move is used instead of copy.

If the above rule would be added to language - then to my best
understanding - there would be no need to use std::move in my example.

My motivation is simple: there are plenty of C++03 where std::move was
not used. So, according to C++11 rules we shall add almost everywhere
this std::move?

BR,
Piotr


--
[ comp.std.c++ is moderated. To submit articles, try posting with your ]
[ newsreader. If that fails, use mailto:std-cpp...@vandevoorde.com ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

[SG]

On Friday, May 30, 2014 10:40:05 PM UTC+2, Piotr Nycz wrote:
> [...]

> So, do you think is it a good idea to add a rule to C++ language that:
>
> If the automatic variable is used as a source for copying and this is
> the last time variable is used - then move is used instead of copy.
>
> If the above rule would be added to language - then to my best
> understanding - there would be no need to use std::move in my example.
>
> My motivation is simple: there are plenty of C++03 where std::move was
> not used. So, according to C++11 rules we shall add almost everywhere
> this std::move?

So far, as you probably know, a compiler is not required nor allowed
to do that. I think there is some value in further analyzing the
impact of such a rule. We would not want this rule to break something.
I've trouble coming up with examples that would break, but it does
not mean that there are none. It would be nice to have a somewhat
formal proof under reasonable assumptions that nothing could go wrong.

Cheers!
sg

[Kalle Olavi Niemitalo]

[Dear moderator, please replace my previous message on this topic.]

SG <s.ges...@googlemail.com> writes:

> So far, as you probably know, a compiler is not required nor allowed
> to do that. I think there is some value in further analyzing the
> impact of such a rule. We would not want this rule to break something.
> I've trouble coming up with examples that would break, but it does
> not mean that there are none. It would be nice to have a somewhat
> formal proof under reasonable assumptions that nothing could go wrong.

#include <memory>
#include <mutex>
std::mutex m;
int i;
void f1(std::shared_ptr<std::lock_guard<std::mutex> > p);
void f2()
{
auto p = std::make_shared<std::lock_guard<std::mutex> >(m);
++i;
f1(p);
++i;
}

If f1(p) automatically changed to f1(std::move(p)), then the
mutex would be unlocked already before the second ++i; statement.

The following example seems more realistic:

#include <cstdio>
#include <string>
void f1(std::string s) {}
int main()
{
std::string s("hello");
const char *p = s.c_str();
f1(s);
std::puts(p);
}

If f1(s) automatically changed to f1(std::move(s)), then the
pointer p would no longer be valid after f1 returns.

[Piotr Nycz]

> > [...]
>
> > So, do you think is it a good idea to add a rule to C++ language that:
>
> >
>
> > If the automatic variable is used as a source for copying and this is
>
> > the last time variable is used - then move is used instead of copy.
>
> >
>
> > If the above rule would be added to language - then to my best
>
> > understanding - there would be no need to use std::move in my example.
>

> > [...]

>
>
>
> So far, as you probably know, a compiler is not required nor allowed
>
> to do that. I think there is some value in further analyzing the
>
> impact of such a rule. We would not want this rule to break something.
>
> I've trouble coming up with examples that would break, but it does
>
> not mean that there are none. It would be nice to have a somewhat
>
> formal proof under reasonable assumptions that nothing could go wrong.
>
>
>

Hello,

sg - thanks for quick response.

Well, I just followed this guidance:
"The public can submit proposed defect reports via the Internet news
group comp.std.c++ "
from C++ standard webpage
(http://www.open-std.org/jtc1/sc22/wg21/docs/standards#14882).

And I have no idea how to find a "formal proof [...] that nothing
could go wrong".

I hope this is everything from my side to raise this issue to C++
standard folks - but if I am wrong - please tell me.

And a general comment: C++11 is great, many things can be written in
more readable, more compact and, what I appreciate a most, shorter
way.
But this one feature, with this "annoying" std::move() needed almost
everywhere - is one thing that really s...

BR,
Piotr

[Daniel Krügler]

Am 07.06.2014 10:33, schrieb Piotr Nycz:
>
> Well, I just followed this guidance:
> "The public can submit proposed defect reports via the Internet news
> group comp.std.c++ "
> from C++ standard webpage
> (http://www.open-std.org/jtc1/sc22/wg21/docs/standards#14882).
>
> And I have no idea how to find a "formal proof [...] that nothing
> could go wrong".
>
> I hope this is everything from my side to raise this issue to C++
> standard folks - but if I am wrong - please tell me.

I couldn't find anything in your description that could be considered
to be comparable to a defect report. As I read it, you have thought
about relaxing the existing rules involving value considerations by
the compiler during copy-like operations. Well, such thoughts have
been expressed a lot of (including by members of the committee), but
those thoughts alone do not imply that there is a defect in the
current rules, because - as Sebastian's response implies - constraints
exist to prevent possible situations that could lead to surprising
results or buggy programs. Not many people would like to get the rumor
to be known as the originator of the "most vexing rule of C++
involving compiler transformations".

If you think that such relaxation of the existing rules should be
considered, I recommend to write a proposal that provides use-cases
and some good reasoning about the advantages and attempts to find
possible disadvantages.

There is no need for any formal proof, that "nothing could go wrong",
but keep in mind that the standard has impact on the code of millions
of line of code and therefore naturally the resistance to introduce
potentially broken rules is high, therefore my advice is that your
proposal should be written having such resistance in your mind. Note
also that the motivation for such a change must exceed a critical
mass. Surely the committee won't change the rules, because someone
argues that he dislikes to write std::move(e) over e. Keep also in
mind, that std::move is not the only possible form to transform the
value category of some expression, so ensure that your wording does
not read as if you don't like the library component std::move.

To write a proposal, please read

https://isocpp.org/std/submit-a-proposal

Given your description, ensure that your proposal addresses the project

"Programming Language C++, Evolution Working Group"

HTH & Greetings from Bremen,

Daniel Krügler

[Piotr Nycz]

> To write a proposal, please read
>
> https://isocpp.org/std/submit-a-proposal
>
> Given your description, ensure that your proposal addresses the project
>
> "Programming Language C++, Evolution Working Group"
>

I am giving up after reading Kalle's counterexamples. Maybe when I
find a way to overcome them, then I return to the subject.

Thanks and BR,
Piotr