4 ms·

The only thing that is statically known here is that you’re wrong. The function I posted only moves its parameter half the time, at random. You may want to trea

by masklinn 10mo ago

The only thing that is statically known here is that you’re wrong. The function I posted only moves its parameter half the time, at random. You may want to treat it as moved-from either way, but factually that’s just not what is happening.

charcircuit 10mo ago
This is like trying to defend that you can't statically know the result of 1 + 2 because: void foo() { std::random_device rdev {}; auto dist = std::uniform_int_distribution<>(0, 1); if (dist(rdev)) { int res = 1 + 2; } } I can tell you for sure that the result of 1 + 2 will be 3.
- 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.
tsimionescu 10mo ago
Yes, looking at some of the code others have shared, I realized where my confusion and mistake was. I mistakenly treated in my mind `foo(obj&& x)` as `foo(obj x)`, which would indeed move or copy statically. But with functions that take an r-value reference, you're of course absolutely right, it becomes impossible to determine statically if they will move or not.

charcircuit 10mo ago

This is like trying to defend that you can't statically know the result of 1 + 2 because: void foo() { std::random_device rdev {}; auto dist = std::uniform_int_distribution<>(0, 1); if (dist(rdev)) { int res = 1 + 2; } } I can tell you for sure that the result of 1 + 2 will be 3.

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.

tsimionescu 10mo ago

Yes, looking at some of the code others have shared, I realized where my confusion and mistake was. I mistakenly treated in my mind `foo(obj&& x)` as `foo(obj x)`, which would indeed move or copy statically. But with functions that take an r-value reference, you're of course absolutely right, it becomes impossible to determine statically if they will move or not.