A possibly more erognomic syntax for borrow

[Xpyder]

as you were replying I realized I didn’t include an explicit copy in my op and added it

[earthengine]

Technically, there is no “explicit copy” available in ANY language, including Rust. In Rust a “move” is just "copy, and make the old location invalid by either drop (call the destructor) or ignore".

[Xpyder]

I guess I consider the default to be an explicit copy, for example in powershell I can do this.

$i=5
$a=i
$a++
$i--
"$i $a"
4 6

The main thing I wanted to do is put in a place to show where and how copy and move are different (it’s out of the scope of this post but in theory wouldn’t implementing a move as a mutable borrow, then drop the old reference and take full ownership be more efficient than a copy and drop for any object larger than 3 pointers in size?)

[earthengine]

In the memory model, both move and copy uses memcpy or something like that. It does not care what the content it is. The only difference is that move require to forget the old location in your brain model, that is all.

[Xpyder]

Sure, but I thought all higher level objects were handled with pointers, so you could be copying a pointer, then dropping the old pointer without actually copying all the data?

An example where you would use this is if you wanted to hand off a vector of vectors to function that would translate it to a csv and write it to a file, but you don’t care about the object after you hand it off. You could pass the object to a thread and then just let it go, without having to check and wait for it to finish so you can empty out the object, and if you had say 500,000 objects you don’t have to duplicate all the data to perform a handoff.

But it sounds like this is something that doesn’t currently exist in RUST so I’ll drop it for now as out of the scope of this post.

[earthengine]

Yes, this is what I was talking about in my another thread.

But for concret types (no dynamic diapatch), you can see my new example_recycler.

[Xpyder]

Interesting, thanks!

[drXor]

I’m gonna clear up a few misconceptions in this thread about how ownership and borrowing work.

// brand new type with no implemented traits
// note that Rust does *not* define copy constructors automatically
struct Foo;

let x = Foo;
let y = x; // move the contents of x into y. at worst this is a memcpy, at best
           // best case, copy elision kicks in. x is now unreadable (and, since
           // it's not `mut`, not writeable, either)
           // note: this does *not* call any destructors. ownership has changed
           // and `x` (now `y`) is not dropped until the end of this scope
let z = x; // error! x has been moved over yonder ^

// define a brand new type with the trivial
// implementation of Rust's equivalent of a copy constructor
#[derive(Clone)]
struct Bar;

let x = Bar;
let y = x.clone(); // explicitly copy the contents of `x` into `y`. mind,
                   // a `clone` might be non-trivial, in the way that copying an
                   // `std::vector` in C++ is more than a memcpy
let z = x; // now `x` has moved, leaving `y` intact...
let a = x; // ...so now this is an error!
let b = y; // but this isn't...
let c = y; // ...but now this is!

// define a brand new type, but make it trivially copyable
#[derive(Clone, Copy)]
struct Baz;

let x = Baz;
let y = x; // `Baz` is `Copy`, so this is not a move, but a semantic copy
           // (though the compiler might still apply copy elision)
let z = x; // which is why this isn't an error- `x` hasn't moved.

// you can totally allocate huge things on the stack- a lot of Rust 
// code is aggresive about not allocating behind the scenes,
// and applies RVO when it can to stop you from making huge 
// copies across call boundaries, just like C++ does
let big_ol_array = [0u64; 1024]; // 64 * 1024 = 65K, as much memory
                                 // as your NES can address!

To get a better picture of how Rust’s move semantics work beyond my sleep-deprived rambling, I suggest checking out the first few chapters of The Book.

[H2CO3]

&mut is confusing to those of us who come from somewhere other than c++

Specifically how is it confusing? It’s probably one of the earliest things you will learn from any introductory Rust guide. If you don’t currently know what it precisely does, then you’ll need to learn about it anyway; no amount of syntax will help that. You can’t make even a keyword-based syntax descriptive enough to convey all the exact semantics, unless, highly unrealistically, the keyword is an 1500-word essay explaining all the details of borrowing.

This also applies to the “I’m not coming from C++” argument. If you are coming from a non-systems language and you are willing to learn a systems language (which is great), then you’ll be exposed to and need to learn more new concepts anyway.

Another reason I oppose this is that, perhaps counter-intuitively, it also creates confusion, because it makes two completely different syntactic forms do the same thing. We already have enough of this phenomenon in the language; we shouldn’t add more if it. Things that look different should behave differently, and things that look similar should behave similarly.

[Xpyder]

Much thanks, that mostly makes sense though I don’t quite get how #[derive(Clone)] enables clone for x…

oh, unless this is implied? let x = Bar::new();

[drXor]

You can’t make even a keyword-based syntax descriptive enough to convey all the exact semantics, unless, highly unrealistically, the keyword is an 1500-word essay explaining all the details of borrowing.

[Xpyder]

[regarding &mut]

Specifically how is it confusing?

when I look at x, &x, and &mut x how can I immediately tell which is a copy/move, a show (both can look), or a loan without memorizing them?

It’s not about the availability of functionality, it’s about intuitiveness and affordances.

you don’t use $xc to declare a function, you use fn because it’s self evident what it means

but & and &mut have no self evident meaning to anyone who isn’t coming from c++

==================

I’ve hit my post limit for the first day, but below this is a response to your post after the #[derive]

If you want to use any programming language, you will have to memorize at least some of its most fundamental syntactic constructs. You can’t get away without that in approximately any case.

Memorization isn’t learning, and I’m going to memorize them in any case. What I’m saying is that it’s a problem for new people coming in, that doesn’t have to be a problem.

[Xpyder]

you don’t have to cover all, that’s silly. But sharing and borrowing are so integral to what makes rust RUST that they deserve to be clear and easy to use for new people coming in.

[drXor]

Much thanks, that mostly makes sense though I don’t quite get how #[derive(Clone)] enables clone for x…

oh, unless this is implied? let x = Bar::new();

No. let x = Bar; is a simplified form of structure initialization syntax, analogous to C’s struct foo x = (struct foo) { .a = 0, .b = 1 };. new is not a keyword in Rust, but rather a very popular name for a factory function serving as “default constructor” (though Rust does not have anything analogous to a C++ constructor).

#[derive(Clone)] invokes a compiler-provided macro that generates an implementation of the Clone trait in, as mathematicians like to say, the stupidest (i.e., most obvious) way possible: by cloning each field of the struct. Of course, this requires that each field be Clone, too.

when I look at x , &x , and &mut x how can I immediately tell which is a copy/move, a show (both can look), or a loan without memorizing them?

Memorize them, in the same way you memorize all the other sigils. xs[n] for addressing lists is a C-ism not present in other languages, for example. You also have to memorize that you call macros with a bang, use +, and that Rust’s (far superior) equivalent of void is pronounced ()!

[Xpyder]

xs[n]

if you mean my_array[10] then yes that syntax is used in almost every single high level language that has arrays, albeit sometimes using different brackets

some examples would be javascript, powershell, ruby, and php all use array[index] syntax

in addition my_array[10] is fairly self evident, if you showed that to someone who didn’t know code but told them my_array is a pocket with 20 names in it, they could probably tell you that code was pulling the 10th name (yes I know it’s actually the 11th, but it’s still clear what the syntax is trying to do)

[drXor]

The Haskellers around these parts would like a word with you. They spell it xs!!n. =p

[H2CO3]

#[derive] is a procedural macro: it’s a method for code generation. When you #[derive(Clone)], the compiler inserts code that implements Clone for your type. Similarly for Copy (and any auto-derivable trait).

[H2CO3]

You can tell that because they are different. & means some sort of borrow – so, as a first approximation, no & means move, & means borrow. I don’t know what you mean by “show”.

without memorizing them

If you want to use any programming language, you will have to memorize at least some of its most fundamental syntactic constructs. You can’t get away without that in approximately any case.

[earthengine]

I don’t know what you mean by “show”.

He means “read only borrow”. This is “&T”. And his “borrow” means “&mut T”.

[Centril]

The Haskellers around these parts would like a word with you. They spell it xs!!n . =p

This is true, and I think OCaml (and other MLs) don’t use arr[idx] as well? (also consider COBOL and other such languages…).

However, I think most Haskellers are multi-lingual and have used some language with arr[idx] at some point.

My take-away from this (interesting) post: Maybe we should make copying more distinct by introducing a prelude function:

fn copy<T: Copy>(x: T) -> T { x }

then you can easily mark copies without making any language-level modifications.