5 ms·

It makes sense...but only because you explained that Vec doesn't implement copy and i32 does. Without scouring the source/docs, or possibly having a mythical ID

It makes sense...but only because you explained that Vec doesn't implement copy and i32 does. Without scouring the source/docs, or possibly having a mythical IDE that can discover this for me, I have to rely on error messages. I just checked, and the error messages are definitely better since January, but I think it would be helpful to have an extra operator just for a visual understanding of the code, rather than enhancing its procedural semantics.

steveklabnik 11y ago
This sort of gets at the root of why using two operators wasn't great: you're basically forcing a human to annotate what a compiler already knows. It doesn't improve the situation significantly, and just adds noise. It's sort of similar to why we don't force you to write out every single type. I'm trying to find the blog post that had an example of the old syntax, but I can't at the moment :/ As you code in Rust, you sort of figure out what should be Copy and what shouldn't: can it be completely copied with a memcpy? Then it's Copy, or it should be. Does it contain a pointer to some sort of external resource? Than it shouldn't be. And, once you've written some Rust, you know what 'use of moved value' is: it means the type moves, not copies. So the error _does_ tell you what's up, although it may not be 100% awesome for completely new people. The error from my first program, trying to print `v` after: hello.rs:5:22: 5:23 error: use of moved value: `v` hello.rs:5 println!("{:?}", v); ^ note: in expansion of format_args! <std macros>:2:25: 2:56 note: expansion site <std macros>:1:1: 2:62 note: in expansion of print! <std macros>:3:1: 3:54 note: expansion site <std macros>:1:1: 3:58 note: in expansion of println! hello.rs:5:5: 5:25 note: expansion site hello.rs:3:9: 3:11 note: `v` moved here because it has type `collections::vec::Vec<i32>`, which is moved by default hello.rs:3 let v2 = v; ^~ hello.rs:3:9: 3:11 help: use `ref` to override `ref` is sort of an awkward suggestion, but it does tell you, it's moved by default.
pcwalton 11y ago
We tried it once, and there was way too much noise. "let move x = move f(move y)" was all over the place. (Yes, you do need it on pattern bindings too if you want to be consistent.)
- masklinn 11y ago
  Since copy is the rarer of the two (I'd assume most developers are not going to opt-in copy unless they need to, even if it's technically feasible not marking a struct as Copy is more future-proof as removing Copy is more likely to break code than adding it) the operator could be `copy`, with everything (including copy-able objects) moving by default, making the language much more uniform. Of course, there would be no point to Copy then, the language could just lost it and require explicit cloning. That would certainly be less convenient for basic numeric types.
  - dbaupp 11y ago
    I think copy may be rarer in terms of the number of types, but I suspect it's not rarer in terms of actual use, since shared references (&) and integers are used a lot.
    - masklinn 11y ago
      Good point wrt reference, I always have trouble thinking of them as "real" types to which the rest of the language applies as usual, thanks for the reminder.

steveklabnik 11y ago

This sort of gets at the root of why using two operators wasn't great: you're basically forcing a human to annotate what a compiler already knows. It doesn't improve the situation significantly, and just adds noise. It's sort of similar to why we don't force you to write out every single type. I'm trying to find the blog post that had an example of the old syntax, but I can't at the moment :/ As you code in Rust, you sort of figure out what should be Copy and what shouldn't: can it be completely copied with a memcpy? Then it's Copy, or it should be. Does it contain a pointer to some sort of external resource? Than it shouldn't be. And, once you've written some Rust, you know what 'use of moved value' is: it means the type moves, not copies. So the error _does_ tell you what's up, although it may not be 100% awesome for completely new people. The error from my first program, trying to print `v` after: hello.rs:5:22: 5:23 error: use of moved value: `v` hello.rs:5 println!("{:?}", v); ^ note: in expansion of format_args! <std macros>:2:25: 2:56 note: expansion site <std macros>:1:1: 2:62 note: in expansion of print! <std macros>:3:1: 3:54 note: expansion site <std macros>:1:1: 3:58 note: in expansion of println! hello.rs:5:5: 5:25 note: expansion site hello.rs:3:9: 3:11 note: `v` moved here because it has type `collections::vec::Vec<i32>`, which is moved by default hello.rs:3 let v2 = v; ^~ hello.rs:3:9: 3:11 help: use `ref` to override `ref` is sort of an awkward suggestion, but it does tell you, it's moved by default.

pcwalton 11y ago

We tried it once, and there was way too much noise. "let move x = move f(move y)" was all over the place. (Yes, you do need it on pattern bindings too if you want to be consistent.)

masklinn 11y ago
Since copy is the rarer of the two (I'd assume most developers are not going to opt-in copy unless they need to, even if it's technically feasible not marking a struct as Copy is more future-proof as removing Copy is more likely to break code than adding it) the operator could be `copy`, with everything (including copy-able objects) moving by default, making the language much more uniform. Of course, there would be no point to Copy then, the language could just lost it and require explicit cloning. That would certainly be less convenient for basic numeric types.
- dbaupp 11y ago
  I think copy may be rarer in terms of the number of types, but I suspect it's not rarer in terms of actual use, since shared references (&) and integers are used a lot.
  - masklinn 11y ago
    Good point wrt reference, I always have trouble thinking of them as "real" types to which the rest of the language applies as usual, thanks for the reminder.