For 1, I think it's hard to make a distinction between swapping an object, vs. swapping/mutating all of its fields such that it becomes equivalent to a different object.
For 3, some objects only need to be pinned under certain circumstances, e.g. futures only need to be pinned after they're polled for the first time, but not before. So it's convenient to separate the pinnability property to allow them to be moved freely beforehand.
I don't quite understand the usecase you have in mind for 4.
> For 1, I think it's hard to make a distinction between swapping an object, vs. swapping/mutating all of its fields such that it becomes equivalent to a different object.
Privacy. If an object has fields I can’t access, but I have an &mut reference, I can indirectly modify them by swapping the object.
More generally, there are a handful of special-seeming things one can do to an object: dropping it, swapping it, forgetting it, and leaking it. Rust does not offer especially strong controls for these except for pinned objects, and even then it feels like the controls are mostly a side effect of pinning.
> For 3, some objects only need to be pinned under certain circumstances, e.g. futures only need to be pinned after they're polled for the first time, but not before.
Is this actually useful in practice? (This is a genuine question, not a rhetorical question. But maybe let’s pretend that Rust had the cool ability to farm out initialization if uninitialized objects described in the OP: allowing access before pinning sounds a bit like allowing references to uninitialized data before initializing it.)
For #4, I’m not sure I have a real use case. Maybe I’ll try contemplating a bit more. Most I think that shared ^ exclusive is a neat concept but that maybe there’s room to extend it a little bit, and there isn’t any fundamental reason that a holder of an &mut reference needs to ensure that no one else can even identify the object while the &mut reference is live.
It's required to do any intialization, particularly for compound futures (e.g. a "join" or "select" type of combinator), since you need to be able to move the future from where it's created to where it's eventually used/polled. I assume some of those cases could be subsumed by &uninit if that existed yeah.
Passing an &uninit to a combinator seems like it would be strange.
But if you told me that some strongly typed language wanted to have coroutines and futures, that coroutine bodies would not execute at all until first polled, and that it was okay to move the thing you have before polling not the thing you had after polling, and I hadn’t seen Rust, I would maybe suggest:
1. Creating a Future (i.e. logically calling an async function) would return an object that is, conceptually, a NotYetPolledFuture. That object is movable or relocatable or whatever you call it (or it’s movable if and only if the parameters you passed are).
2. Later you exchange that object for a LiveFuture, which cannot be moved.
Rust has two limitations that would make this awkward:
- Rust doesn’t actually have immovable objects per se.
- The exchange is spelled fn exchange(val: Type1) -> Type2, which doesn’t work if Type2 is immovable.
But the &uninit/&own proposal in the OP is actually secretly a complex scheme using lifetimes to somewhat awkwardly do an in-place exchange from an uninitialized type to an initialized and owned type. Maybe that proposal could be extended a little bit to allow type exchanges. (Maybe it already does, sort of? You could pass an &uninit Future and a FutureToken and get out an &own Future, with the caveat that this would force the fields in the token to be moved unless the optimizer did something truly heroic.)
People aren't complaining about that. What you do in the privacy of your own computer is only your problem. The issue is people pouring a whole "arduous" 2 hours into vibecoding a project, then advertising it and posting to communities everywhere as a revolutionary bullet-proof high-quality project asking for visibility and contributions.
This post mirrors my sentiment and the reasons I dislike these sorts of "projects" much more closely than the main site does, deserved to be the main submission, in retrospect.
I thought that the implication was that the shader compiler produces a second shader from the same source that went through a dead code elimination pass which maintains only the code necessary to calculate the position, ignoring other attributes.
Sure, but that only goes so far, especially when users aren't writing their shaders with knowledge that this transform is going to be applied or any tools to verify that it's able to eliminate anything.
Well, it is what is done on several tiler architectures, and it generally works just fine. Normally your computations of the position aren't really intertwined with the computation of the other outputs, so dead code elimination does a good job.
I was lost when it suddenly jumped from a long retrospective on GPUs to abruptly talking about "my allocator API" on the next paragraph with no segue or justification.
A 'static lifetime does not live for the rest of the program. It rather is guaranteed to live for as long as anyone is able to observe it. Data allocated in an Rc for example, lives as long as there are references to it. The ref count will keep it alive, but it will in fact still be deallocated once all references are gone (and it cannot be observed anymore).
That is not a memory leak though! That's using/exposing an uninitialized buffer, which can happen even if you allocate and free your allocations correctly. Leaking the buffer would prevent the memory region from being allocated by another application, and would in fact prevent that from happening.
This is also something that Rust does protect against in safe code, by requiring initialization of all memory before use, or using MaybeUninit for buffers that aren't, where reading the buffer or asserting that it has been initialized is an unsafe operation.
It's a security hole. Rust doesn't prevent you from writing unsafe code that reads it. The bug wasn't that it could be read by a well conforming language, it was that it was handed off uninitialized to use space at all.
I feel like you're attacking a strawman here. Of course you can write unreliable software in Rust. I'm not aware of anyone who says you can't. The point is not that it's a magic talisman that makes your software good, the point is that it helps you to make your software good in ways other languages (in particular C/C++ which are the primary point of comparison for Rust) do not. That's all.
> The point is not that it's a magic talisman that makes your software good, the point is that it helps you to make your software good in ways other languages (in particular C/C++ which are the primary point of comparison for Rust) do not.
