From Stacks to Trees: A new aliasing model for Rust

Post by FpUser » Sun, Jun 11, 2023, 10:54 PM UTC

imron wrote: post #8

Osiris wrote: post #7

Earlier quoted context omitted.

I’ve been learning rust and I spend the vast majority of my time dealing with lifetimes and borrow checking. Common ways in used to doing things simply don’t work in rust and a lot of effort has to go into keeping track of how and where data is used. I’ve worked in OOP languages, functional languages, and dynamic languages but all of them were essentially garbage collected, so having to keep track in my head of how d…

As a c++ programmer, one of the great things about rust is that I no longer have to keep track of data ownership and management in head. I can outsource this to the compiler and if I get it wrong the program won’t compile. In c++ you still need to do all the same tracking and management if you want safe and correct programs, but you don’t get nearly as much help from the compiler if you make a mistake.

Post by Ygg2 » Sun, Jun 11, 2023, 10:57 PM UTC

FpUser wrote: post #3

MuffinFlavored wrote: post #2

fn two_phase(mut x: Vec ) { let arg0 = &mut x; let arg1 = Vec::len(&x); Vec::push(arg0, arg1); } > This code clearly violates the regular borrow checking rules since x is mutably borrowed to arg0 when we call x.len()! And yet, the compiler will accept this code Does anybody else wish the compiler wouldn't and would be even more verbose? I know one of the biggest learning curves (personally) for Rust is the borrow che…

>"Does anybody else wish the compiler wouldn't" Compiler being obtuse and not being able to figure when it is safe to "break rules" is the problem. Not twisting brain of the programmer into being "safe compiler". This sounds like a Stockholm syndrome. >"you should be following immutable practices" No I should not. I should do what makes sense in particular situation and not bending over for some zealots trying to enf…

Post by saurik » Sun, Jun 11, 2023, 11:05 PM UTC

Georgelemental wrote: post #13

saurik wrote: post #11

> ...by the time x.len() gets executed, arg0 already exists... So, I realize that this is the way that Java does it--and, presumably, one still doesn't get fired for doing whatever Java does ;P--but, would it not actually make more sense for the arguments to be evaluated before the target reference, making the argument order more like Haskell/Erlang (but very sadly not Elixir, which makes it awkwardly incompatible wi…

In Rust, `reciever.some_method(whatever)` is supposed to be relatively thin sugar for `TypeOfReciever::some_method(receiver, whatever)`. So the evaluation order should be the same for those two forms.

Post by estebank » Mon, Jun 12, 2023, 12:06 AM UTC

saurik wrote: post #16

Georgelemental wrote: post #13

Earlier quoted context omitted.

In Rust, `reciever.some_method(whatever)` is supposed to be relatively thin sugar for `TypeOfReciever::some_method(receiver, whatever)`. So the evaluation order should be the same for those two forms.

Sure, but I am saying it would actually have made more sense to put receiver as the last such argument--as one might expect from having used Haskell/Erlang--given the other design decisions clearly in play here, as the target reference isn't really the first argument for any obvious reason other than visual effect and some historical baggage from implementations of some object-oriented languages (including Java) with…

Post by comex » Mon, Jun 12, 2023, 2:20 AM UTC

estebank wrote: post #18

saurik wrote: post #16

Earlier quoted context omitted.

Sure, but I am saying it would actually have made more sense to put receiver as the last such argument--as one might expect from having used Haskell/Erlang--given the other design decisions clearly in play here, as the target reference isn't really the first argument for any obvious reason other than visual effect and some historical baggage from implementations of some object-oriented languages (including Java) with…

You're not wrong, but making self be the last argument would cause confusion for almost everyone coming from other languages, and for Rust it is too late to change that now. You could special case the behavior of the method call syntax to operate that way without breaking backwards compatibility (at the cost of making going back and forth between that syntax and the fully qualified call no longer being a straight for…

    {println!("first"); 1u32}.wrapping_add({println!("second"); 1});