Implicit move on return?

[Pavel Minaev]

I've noticed that, when returning a local variable from a function, the temporary object that represents the function result seems to be created by copying the return value, rather than moving it as in C++11. E.g. in this C++ code:

   Foo getFoo() { Foo foo; return foo; }

   int main() { Foo foo = getFoo(); }

I observe a move ctor invocation for Foo. However, with this seemingly equivalent Clay code:

   getFoo() { var foo = Foo(); return foo; }

   main() { var foo = getFoo(); }

I observe copying; specifically, if I have two record overloads like so:

  overload Foo(rvalue other: Foo)

  overload Foo(ref other: Foo)

I see the ref overload being called, rather than rvalue overload (for that matter, I actually expected copy() - which I had also overloaded - to be called in those circumstances, but it wasn't).

So it seems that I need to always write "return move(...)" to take advantage of move semantics when returning lvalues that will go away right after return completes? Is that intentional? Or am I not getting something about how copy/move works in Clay?

[Joe Groff]

On Mar 11, 2012, at 3:30 PM, Pavel Minaev <int...@gmail.com> wrote:

> So it seems that I need to always write "return move(...)" to take advantage of move semantics when returning lvalues that will go away right after return completes? Is that intentional? Or am I not getting something about how copy/move works in Clay?

You're not missing anything; that's just how the compiler works
currently. Automatic NRVO is not implemented yet, but would be a good
idea.

-Joe

[Matt Calabrese]

I know I'm a few months late, but I just found out about Clay. Maybe it's the way your reply is worded, but I think you may have missed what Pavel meant. In C++, returning from an object from a function is a move operation as opposed to a copy operation. NRVO is often used so that neither operation is actually performed, but the presence of NRVO doesn't really affect his point. Even if NRVO were implemented in Clay, you'd still have to be explicit about move, which definitely seems like a mistake.

[Joe Groff]

On Fri, Sep 14, 2012 at 9:52 AM, Matt Calabrese <riv...@gmail.com> wrote:
> I know I'm a few months late, but I just found out about Clay. Maybe it's
> the way your reply is worded, but I think you may have missed what Pavel
> meant. In C++, returning from an object from a function is a move operation
> as opposed to a copy operation. NRVO is often used so that neither operation
> is actually performed, but the presence of NRVO doesn't really affect his
> point. Even if NRVO were implemented in Clay, you'd still have to be
> explicit about move, which definitely seems like a mistake.

Yeah, implicit move with NRVO if possible would be how Clay should do
it, just like in C++11. See
https://github.com/jckarter/clay/issues/238 . Currently Clay does not
distinguish automatic-storage variables from other references, so
explicit move is always required, though that should be fixed.

-Joe

[Matt Calabrese]

On Friday, September 14, 2012 1:11:48 PM UTC-4, Joe Groff wrote:

Yeah, implicit move with NRVO if possible would be how Clay should do
it, just like in C++11. See
https://github.com/jckarter/clay/issues/238 . Currently Clay does not
distinguish automatic-storage variables from other references, so
explicit move is always required, though that should be fixed.

-Joe

Okay, great!