Beyond the &

Posted by PaulHoule 1 day ago

Comments

Comment by weinzierl 13 minutes ago

"A place is Rust's equivalent of C's left-hand sides (lvalues): a location that values can be read from or written to. The difference between a place and a pointer is that a place is an abstract expression that exists at compile time, such as state.cache, and a pointer is one way to represent a place at run time."

That was a helpful bit.

Comment by chombier 5 hours ago

Recording of the talk: https://www.youtube.com/watch?v=bXs56902ElY

Comment by creata 6 hours ago

> That works, but it's not particularly intuitive.

It looks fine? The code fails because it dereferences the MutexGuard twice, so you instead dereference it once. It's hard to imagine that this contributes much to "Rust's difficult learning curve".

Rather, introducing even more potential implicitness on every `.` seems like it would make the language harder to learn.

Is there an example that really benefits from these features?

Comment by masklinn 4 hours ago

> Rather, introducing even more potential implicitness on every `.` seems like it would make the language harder to learn.

The problem is that built-in pointers (references and box) are already special cased in the compiler to Just Work (tm), so this creates confusion when switching between those builtins and third-party pointers, or even stdlib pointers which aren’t special cased by the compiler.

So this is less about “potential implicitness on every .” and more about making places more first-class, and non-builtin smart pointers (both first and third class) being better able to express their semantics to the compiler, to lift every pointer to the ergonomic capabilities of builtins.

Comment by ivanbakel 1 hour ago

It's missing the point of these changes to suggest that the current version is good because the error has a just-so explanation. The same code without the MutexGuard is conceptually the same, and there a mutable reference is dereferenced twice without an error. Should the programmer need to know that they themselves need to manually write the mutable-reference coercion that the compiler would normally do to unlock the same expressivity? Is this good and intuitive language design?

>Is there an example that really benefits from these features?

That question would be easier to answer if you would spell out what you don't find compelling about the article's example, beyond the fact that you can identify a reason for the error to occur.