A possibly more erognomic syntax for borrow

language design
21 
[regarding &mut]

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]

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.

22

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.

23

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.

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 ()!

1 Like
24

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)

25

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

1 Like
26

#[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).

27

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".

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.

6 Likes
28

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

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

29

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. :slight_smile:

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.

2 Likes
30

Yep, in OCaml, you have v.(n) for arrays, v.[n] for strings, v.{n} for Bigarray(C compatible non-GC'd array), and you can define new indexing operators on OCaml 4.06 onwards. Quite close though. (Not at all important to the thread here, just thought I'd add.)

I'd say that intuitiveness and affordances are extremely subjective - what would be extremely intuitive to you might be extremely foreign and obscure to me, and vice versa. (For example, Python might be the perfect tool in your field, while it gives me headache every single time.)

I don't think it's reasonable to have a general purpose language that caters for intuitiveness to only quite specific groups where the added meaning is not portable(of no value in understanding) to other groups.

31

Also make a macro (and a enum):

enum Moved{}
macro_rules! undefine {
    ($v:ident) => {
        let $v: Moved;
    }
}
32

There is truth here which is why I'm saying we should keep the existing way of doing things. But Look and Borrow are well known life concepts to anyone who grew up in America and Europe, who are the majority of the expected Rust user base. I'd be interested to hear from someone who teaches Rust about how often new students get hung up on & and &mut?

And to be clear I can get a handle on them pretty quickly, even just going through this discussion I've pretty much got it within the first day, but I'm not average. Most likely none of us are. We all likely have a lot of experience with different programming languages, but I work with enough non-programmers to be able to tell you that this

let x = &a
let y = &mut b

is harder for them to understand than this

let x = look a
let y = borrow b

it's the exact same functionality in the exact same grammar, and the compiler doesn't actually care which version we use.

With the widening popularity of things like the MEAN stack and the ease of programming web apps we're going to get a lot more people exploring Rust who don't come from our same background with our same advantages, for whom mentally swapping symbology for words isn't as easy as it is for us.

Based on this video here it seems like Rust is trying to be more ergonomic for this new breed of programmer, and I'm just trying to make sure we don't alienate them by showing them something that looks intimidating when it would be just as easy to alias it to something they they can bring from their daily life.

34

I’m going through the Rust book and it sounds like there may be a deeper problem here, specifically the way the term Borrow has been used.

In life, If I loan a book to someone, and they take it with them to do something, I can’t look at that book while they’re borrowing it since they have it and I don’t. And if I show someone a book I have, we can both look at it since I haven’t given it to them

In rust, If someone “borrows” a pointer, both them and I can look at the data in than pointer (closer to a show or look in life). And there’s no analogous term for when someone uses a mutable reference in rust (which is much closer to a real life borrow)

Is this the way Borrow has been used in Rust’s documentation? And if so is there a particular reason it was chosen to be applied to & rather than &mut?

NOTE: I’m not (yet) positing we should change this, that would be a massive discussion all it’s own and require it’s own (several) threads to decide. I’m just trying to make sure I understand some of the confusion that’s coming up.

35

I agree with you that the analogy of “borrow” like a book fails pretty fast. I like to think of it as:

  • & : shared viewing (you and I and maybe others “looking” at the book together, but, none of us can change it, not even turn the page)
  • &mut : borrow - you take the book, but, will give it back when you are done. You can even write in it if you want or turn the page.
  • owned/move : I give you the book. You make no promise to ever give it back. It’s yours now.

So, I agree that using “borrow” for both & and &mut is somewhat and incorrect mental model.

36

Ok, given this, and some of the things about stability in the rust early days mentioned here it’s possible & and &mut were chosen specifically because they aren’t words; at least until we can settle on a solid base of terminology, which may be an interesting discussion all it’s own.

Does anyone have any suggestions which forum we should bring that discussion to, until we’ve built up a reasonable concensus on terms and possibly fill out this table to try and prevent this sort of vernacular collision?

.              | friend can't look | friend can look | friend can write
-------------------------------------------------------------------------
you can't look |  deleted          |                 | loan/borrow
-------------------------------------------------------------------------
you can look   |                   | show / look     | 
-------------------------------------------------------------------------
you can write  |  owned            |                 | shared (dangerous)
37

This is not permitted in "safe" rust. Only "unsafe" through pointer manipulation and de-ref can have this.

38

The “best” syntax depends on the target audience, and whether you’re targeting learnability or efficiency.

For example, very-short-term studies for non-programmers say you want repeat 5 times, not for _ in 0..5; integer, not int; number, not double or real; never use ==; :Get(0), not [0]; action, not fn; etc: An Empirical Investigation into Programming Language Syntax (Stefik & Siebert, 2013).

The question that’s much harder to study is whether fn being shorter makes it more efficient than action once someone has learned the language.

39

You're both correct, there's definitely a larger discussion to be had here that deserves it's own main post. Is this the correct forum for me to start that post in?

NOTE: I should clarify that chart isn't yet for final terms, just the closest words we can find in English (American, British, English, or otherwise) to match these concepts even if they aren't yet implemented in Rust, my hope would be for it to serve as a guideline for further discussion and a reference point if a function for another of these matrix boxes shows up at some point.

40

And after re-reading through your post I also agree there's a deeper discussion to be had about this.

But trying to have it before the documentation is "fixed" (either corrected or locked in place with an explanation of why) we're going to end up with people using the same terminology for different concepts which I anticipate will get unmanageably confusing and tie the discussion into knots.

And ty for linking sources so we can all be on the same page once we are ready for that discussion :slight_smile:

41

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.