Then explain to me why it matters. If none of the toy examples in the research actually required multiple mutable references to the same objects, then why would it matter that the compiler allowed it? I think you missed the point of the research: to "explor[e] the usability costs of the restrictions that Rust imposes."
If they didn’t require it, then that would significantly strengthen the paper! They could have not exposed that API and it would be much more useful. I suspect that they probably did need it though. An immutable GC would only be useful by adding an interior mutability wrapper, which is exactly the kind of friction the paper is trying to avoid.
It matters because the rest of the Rust universe follows this pattern. If they coded their own standard library (and any other allowed libraries) and modified the compiler to not miscompile this usage, then that exploration would be valid. But you’re also going to get friction from miscompiles and fighting with other APIs that do have this property. So it would be more useful to either go all-out ok this idea that Rust’s uniqueness properties are a bad thing, or fix the soundness issues. The halfway step simply confounds too many issues to be truly useful, in my opinion.
I agree that exploring the space is a good idea and useful. My issue is with the methodology, not the concept.
The article does include a thorough description of the tasks. Afaict, none of them requires multiple mutable references to the same objects. It would be strange if any task did as it then wouldn't be implementable in plain Rust.
I think you are missing the point of this research. The author has, given his large sample size, persuasively demonstrated that Rust's borrow checker is confusing to newbies. Data from 428 students is a lot and an order of a magnitude more than many other programming language usability studies. This is in my opinion interesting research, even though I understand why Rust fans doesn't like his results!
> Afaict, none of them requires multiple mutable references to the same objects
They ask to store objects ("turtles") into a single Vec. Two turtles from that Vec can breed to create a child turtle stored in that same vec. Parents must retain a reference (a real ref, not an index or other workaround) to their children, meaning that children have multiple refs. Children can become parents themselves, so all the turtles are mutable.
There you have it: multiple mutable references to the same object. With proper Rust you'll need some kind of RefCell to implement this (convoluted) design. The runtime check will ensure a runtime panic if you try to make the same object mutable via different RefCells (trying to breed a turle with itself). With BronzeGc the compiler will believe that they are different objects, and UB-optimize accordingly.
I don’t think you understand why, given that as myself and several people have stated, the issue isn’t with the results. It’s with the methods. I have no opinion either way about the results, because as far as I can tell, they result from an incoherent premise, which means the conclusion is also incoherent.
> An immutable GC would only be useful by adding an interior mutability wrapper, which is exactly the kind of friction the paper is trying to avoid.
This would be the most idiomatic approach, yes. They could use a code transformation to automate the 'wrapping' and present an intuitive, frictionless interface to the developer.
Totally, and that’s one of the ideas floated in the issue. I think depending on how it could be done it may not even lost out on ergonomics in most cases, but I haven’t worked through it myself.
