Hacker News Reader

Comment by quietbritishjim | Hacker News Reader

Does anyone know what the move / copy semantics are in Carbon? I can't figure it out from the docs (admittedly I have not looked hard at all).

I would say the number one weakness of C++ is its model of copy by default and often by surprise. For example: f(std::move(x)) will copy x if x is const or f takes its value by const ref - rather than a compiler error as you might reasonably expect (if you don't know the C++ reference model inside out).

In Rust, moves are destructive (which simplifies implementions - you don't need an "empty" state) and always bitwise (which is usually fine, so long as they're destructive); and copies are always explicit so you don't have the above problem. I personally think that is all more useful than the borrow checker.

If Carbon has the same bizarre move/copy rules as C++ then the effort is wasted IMO.

View on HN

> In Rust, moves are destructive (which simplifies implementions - you don't need an "empty" state) and always bitwise (which is usually fine, so long as they're destructive); and copies are always explicit so you don't have the above problem.

Rust has implicit copies too, e.g. if you do:

    let v = 2u16;
    foo(v);

then v is being copied. What Rust does not have is implicit deep copies. The auto-copying depends on the type and is only done for types that don't have a custom destructor, or to be more precise, implement the Copy trait. So a big array of integers gets copied (because it implements the Copy trait), but a Vec gets moved (because of its custom destructor there is no Copy trait implementation).

As Rust's documentation explains "... Under the hood, both a copy and a move can result in bits being copied in memory, although this is sometimes optimized away"

What's important about Copy is that, since you said you want to permit Copy here, it's OK if Rust keeps both identical bit patterns alive after the bits are copied. Just keeping both alive is obviously better for trivial types like u32, but on modern hardware it's also true for somewhat more complicated types like &str (which is a pointer and a count) or SocketAddrV6 (an IPv6 address, a port number, flow label and so on).

Thus, in your example, v is being bit copied (at least notionally) in both cases to become the parameter of this foo function, but because v is Copy, we can nevertheless use v again on the next line, the bits in v are still alive. If v was not Copy (e.g. an owned String) then foo(v) consumes v, it's moved into foo and now it's gone, we can't access v on the next line.

The fact that foo(v) consumes v, is why core::mem::drop() is so trivial: https://doc.rust-lang.org/core/mem/fn.drop.html

Sure, I knew about the Value trait but I thought it wasn't relevant for the general point (and I thought that sentence had too many parenthesised clarifications already!).

In Rust, types implement the Copy trait and the Drop (destructor) trait independently. Vec could easily implement Copy. It doesn't because copying a Vec requires an expensive heap allocation, which can surprise users when it happens implicitly.

No you can't, there is a specific error for that. You can try it:

    struct Foo;
    
    impl Copy for Foo {}
    impl Drop for Foo {
        fn drop(&mut self) {
            // ...
        }
    }

It gives the error:

    error[E0184]: the trait `Copy` may not be implemented for this type; the type has a destructor
     --> src/main.rs:3:1
      |
    3 | impl Copy for Foo {}
      | ^^^^^^^^^^^^^^^^^^^^ `Copy` not allowed on types with destructors

See also the "When can't my type be Copy?" section of the Rust documentation: https://doc.rust-lang.org/1.62.0/std/marker/trait.Copy.html#...

Without the borrow checker, this "move-by-default, move is memcpy" semantics would break all hell loose. Dangling pointers/references would be everywhere. I like this part of Rust, but I'm not sure if it can work in a non-GC, no-borrow-checker language.

You don't need a full-on borrow-checker to make move-by-default safe.

If you can track whether or not a variable has been (definitely) initialized, you can track whether or not a variable has been moved from. It's the same basic logic. And there are languages without full borrow checkers that can do that--Java is the first one that comes to mind.

Don't you need to know when all borrows end? E.g. here:

  fn main() {
      let x = [1, 2, 3];
      println!("{:?}", x);
      let y = x.map(|x| x % 2 == 0);
      println!("{:?}", y);
  }

x is borrowed by println (or rather by code that println expands to) and then it is moved by array::map. The compiler needs to know that before x.map(), x is not borrowed anymore. Otherwise it could be that println actually stored a reference to x somewhere and now you have a dangling reference possibly breaking type-safety (referring to an array of bools through a reference to array of ints, if the map is implemented as an in-place operation).

Sure but that is already a risk in C++ at the moment.

   void foo() {
       if (true) {
           Foo f;
           stores_a_reference_to_foo(&f);
       }
       uses_stored_reference_to_foo();
   }

I see that destructive moves would in theory introduce more opportunities for that, but I don't really see it making a big difference in practice - routines that take a pointer/reference and hold onto them (without taking ownership) already need a lot of care in C++.

Without a borrow checker, you won't be able to eliminate dangling reference issues. But that's an orthogonal issue to move safety.

You would need to add the rule that you can't move from a variable in only one branch of an if statement or from any sort of loop. Like a really primitive compile time borrow checker.

It seems to me that would be enough, but maybe I haven't thought it through properly, or maybe you'd end up having to copy a lot more often than you want to (or use optional half the time, which might defeat the point a bit).

> Does anyone know what the move / copy semantics are in Carbon? I can't figure it out from the docs (admittedly I have not looked hard at all).

I read the documentation and had the very same question. My notes from the announcement thread had this line in it:

> * Not clear from the main design document is how the distinction--if any--between trivial/nontrivial copy/move types work. There appears to be an explicit move operator (with obvious syntax ~x), so support for nontrivial move or immovable is better than Rust already, but the avoidance of a NRVO setup still makes me wonder what the actual story is here.

Given that Carbon copies the signed-no-overflow/unsigned-may-overflow distinction from C/C++, it wouldn't surprise me if they also copy the move/copy rules from C++, as those are both rather fundamentally baked into C++ (which means you have to deal with it for automatic translation), even if they are pretty objectively confusing.

The move situation would be less confusing to newcomers if they had called it what it really does, std::become_rvalue_reference or something.

I agree that it should have been named better (rvalue_cast might have worked) but that wouldn't have solved the core problem: Does f(std::become_rvalue_reference(x)) make a copy of x? It's more obvious that it might but I still lack the facility to make it cause a compile time error if it would (except changing x's class to disallow any copies at all).

In general you can't answer these questions by reading the call site. You have no idea what kinds of intermediate functions are implied by f(x). Maybe f() doesn't take an X at all, maybe it takes a Y and there's an implicit Y::Y(const X&) hanging around, or perhaps there is an X::operator Y(). You can only understand f(x) by reading the definitions of f, its argument type, and X.

alternatively move should have been a real move:

  template<class T> T std::move(T&& t) {
    return T(static_cast<typename std::remove_reference<T>::type&&>(t));
  }

But it would have had performance implications.

Interesting - that prevents one of the two cases.

Given fn(const Foo&) (or fn(Foo&)), your implementation would stop fn(move(x)) from compiling.

But given fn(Foo) and const Foo x, your implementation would still allow fn(move(x)) to compile and perform a copy.

The Foo& case won't compile. Const foo& will as temporaries can bind to const references; this is desirable and x is still moved from.

The plain Foo case won't do any copies because of NRVO and temporary elision (both optimizations are now guaranteed by the standard); again x will be moved from.

The upside of this implementation is that x is always moved from. The downside is that sometimes more objects are created (for example in the const&) than the pure cast case and can't always be reliably optimized out.

> The Foo& case won't compile. Const foo& will [compile]

Not true. Both Foo& [1] and const Foo& [2] parameter types fail to compile (in gcc 8.5, I also tried gcc 10 with same result).

Bizarrely, in more modern compilers, including gcc 11, both Foo& [3] and const Foo& [4] do compile, even with the language version forced to C++11. I'm very curious to know why; presumably there's some defect report that got retroactively applied to all standards, but I can't find anything relevant. In any case, this illustrates how cryptic the C++ rvalue rules are.

[1] https://godbolt.org/z/97Yse4jWY

[2] https://godbolt.org/z/Gsj83zes6

[3] https://godbolt.org/z/xWhG9cxKn

[4] https://godbolt.org/z/xadn7Txh4

> Const foo& will as temporaries can bind to const references; this is desirable and x is still moved from.

Well that (it's desirable) is your opinion! In my view, in an ideal world, f(move(x)) would not mean there is at least one move... it would mean there are at most zero copies.

It doesn't compile because the code is wrong :).

I forgot remove reference for the T in the result type and in the return statement.

Interestingly it compiles with gcc-12 for some reason.

In generic code you do want to copy if T is not movable (for example when implementing a container). The annoying thing with the existing std move is that it might or might not move from the x depending on the implementation of the sink. This implementation will always move from if x is movable.

Different tradeoffs.

Now can we make a move with your requirements (only move no copy?) I think so. Let me think about it.

Reply on news.ycombinator.com