3 ms·

> This is like trying to defend that you can't statically know the result of 1 + 2 It is completely unlike that. tsimionescu is asserting that they can always

by masklinn 10mo ago

> This is like trying to defend that you can't statically know the result of 1 + 2 It is completely unlike that. tsimionescu is asserting that they can always know statically whether `foo` will move its parameter. The function I provided is a counter-example to that assertion. Of course the branch body always moves, that's what it's there for. That has no bearing on the argument.

charcircuit 10mo ago
>Of course the branch body always moves >That has no bearing on the argument. That is the whole argument. Let me quote the other person: "My claim is that, if I call `foo(std::move(myObj))`, it is statically knowable if `foo` receives a copy of `myObj` or whether it is moved to it." It is saying that for "auto pp = std::move(p);" we will know if it uses the move assign constructor or the copy assign constructor.
- masklinn 10mo ago
  > That is the whole argument No, it is not. > Let me quote the other person: "My claim is that, if I call `foo(std::move(myObj))`, it is statically knowable if `foo` receives a copy of `myObj` or whether it is moved to it." Yes. `foo`. > It is saying that for "auto pp = std::move(p);" we will know if it uses the move assign constructor or the copy assign constructor. `pp` is not `foo`. That `pp` uses a move constructor is not the subject of the debate. You can literally take the function I posted, build a bit of scaffolding around it, and observe that whether the parameter is moved into `foo` or not is runtime behaviour: https://godbolt.org/z/jrPKhP35s https://godbolt.org/z/jrPKhP35s
  - charcircuit 10mo ago
    Taking a step back I think the issue is that your foo takes an rvalue reference. Which is not the case we are talking about which is whether a move or copy constructor is used when constructing the parameter of foo.
    - knorker 10mo ago
      What do you mean by "move or copy constructor is used when constructing the parameter of foo"? Nothing is constructed at call time. Check out this example, which compiles just fine, even though Foo is neither copy nor move constructible/assignable: https://godbolt.org/z/Wj57o773d https://godbolt.org/z/Wj57o773d "&&" is just a type system feature, resolving function polymorphism matching rvalue reference and not lvalue reference. It's not a thing that causes a move.

charcircuit 10mo ago

>Of course the branch body always moves >That has no bearing on the argument. That is the whole argument. Let me quote the other person: "My claim is that, if I call `foo(std::move(myObj))`, it is statically knowable if `foo` receives a copy of `myObj` or whether it is moved to it." It is saying that for "auto pp = std::move(p);" we will know if it uses the move assign constructor or the copy assign constructor.

masklinn 10mo ago
> That is the whole argument No, it is not. > Let me quote the other person: "My claim is that, if I call `foo(std::move(myObj))`, it is statically knowable if `foo` receives a copy of `myObj` or whether it is moved to it." Yes. `foo`. > It is saying that for "auto pp = std::move(p);" we will know if it uses the move assign constructor or the copy assign constructor. `pp` is not `foo`. That `pp` uses a move constructor is not the subject of the debate. You can literally take the function I posted, build a bit of scaffolding around it, and observe that whether the parameter is moved into `foo` or not is runtime behaviour: https://godbolt.org/z/jrPKhP35s https://godbolt.org/z/jrPKhP35s
- charcircuit 10mo ago
  Taking a step back I think the issue is that your foo takes an rvalue reference. Which is not the case we are talking about which is whether a move or copy constructor is used when constructing the parameter of foo.
  - knorker 10mo ago
    What do you mean by "move or copy constructor is used when constructing the parameter of foo"? Nothing is constructed at call time. Check out this example, which compiles just fine, even though Foo is neither copy nor move constructible/assignable: https://godbolt.org/z/Wj57o773d https://godbolt.org/z/Wj57o773d "&&" is just a type system feature, resolving function polymorphism matching rvalue reference and not lvalue reference. It's not a thing that causes a move.