Rendered at 16:21:26 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
weinzierl 5 hours 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 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?
masklinn 10 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.
ivanbakel 6 hours 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.
creata 3 hours ago [-]
> 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.
It's not just that there's a reason for the error to occur, it's that (1) the line between what the borrow checker can and can't do is currently clear, even if it's privileging references and boxes, and (2) the fix is a one-line change. Exposing more language hook points via traits to save one line here and there is what doesn't seem compelling to me, which is why I asked for an example where it leads to a more significant improvement in the code.
Like, the mentioned roadmap page says "But Option<&mut T> or custom smart pointers require awkward .as_deref_mut() or .reborrow() calls"; what I'm asking is: how awkward?
NooneAtAll3 5 hours ago [-]
I don't understand, how is this connected to Linux?
Why is it on linux news blog?
masklinn 4 hours ago [-]
I don’t know, maybe because rust is of interest to the wider Linux community and has been pretty much since its inception (https://lwn.net/Articles/547145/)?
And with the inclusion of rust in the kernel, and thus the kernel’s need to express its own abstractions and requirements (as well as the impossibility to use alloc and thus box) the limitations (ergonomic and otherwise) of “userland” smart pointers are more salient and relevant than ever.
azornathogron 4 hours ago [-]
LWN.net doesn't exclusively cover Linux kernel issues. From the FAQ,
What is this LWN thing?
LWN.net aims to be the premier news and information source for the free software community. We provide comprehensive coverage of development, legal, commercial, and security issues.
That was a helpful bit.
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?
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.
>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.
It's not just that there's a reason for the error to occur, it's that (1) the line between what the borrow checker can and can't do is currently clear, even if it's privileging references and boxes, and (2) the fix is a one-line change. Exposing more language hook points via traits to save one line here and there is what doesn't seem compelling to me, which is why I asked for an example where it leads to a more significant improvement in the code.
Like, the mentioned roadmap page says "But Option<&mut T> or custom smart pointers require awkward .as_deref_mut() or .reborrow() calls"; what I'm asking is: how awkward?
Why is it on linux news blog?
And with the inclusion of rust in the kernel, and thus the kernel’s need to express its own abstractions and requirements (as well as the impossibility to use alloc and thus box) the limitations (ergonomic and otherwise) of “userland” smart pointers are more salient and relevant than ever.
What is this LWN thing?
LWN.net aims to be the premier news and information source for the free software community. We provide comprehensive coverage of development, legal, commercial, and security issues.
https://lwn.net/op/FAQ.lwn