Re:Compiling Rust for .NET, using only tea and stubbornness
by CharlieDigital on Tuesday August 29, 2023 @10:39AM
(#37308634)
This seems more like a concurrency issue, then. If that's the case, it seems like the right answer is some synchronization primitive or perhaps using a `Channel<T>` to serialize the flow.
[ Parent
| on HN ]
Re:Compiling Rust for .NET, using only tea and stubbornness
by colejohnson66 on Tuesday August 29, 2023 @11:12AM
(#37309110)
Sometimes it's concurrency, but most of the time it's that I want to know I own the array. I want to know that `_array[5]` will be the same, no matter when I access it (excluding intentional modifications by callee). For example, if I take `T[]` as a parameter to my constructor, I might think `_array[5]` will be the same, but nothing stops the caller from doing `Array.Sort(theParameter)` sometime later.
// in one function of the caller's type
_data = new int[] { 1, 2, 3, 4, 5, 6, 7 }; // could come from some data collection engine
_dataTable = new(_data);
// then, sometime later, in another function of the caller's type
Array.Clear(_data); // reset for next iteration or something
// data table now has an array of zeros if it didn't copy the data
This is just an example, and the problem is not only limited to arrays; Mutable classes can be mutated by the caller after the callee is given them. Basically, the issue is multiple mutable references. The only solution to the above problem is a defensive copy by the "data table" constructor. I would like the ability to say, "the caller cannot modify this reference anymore".This is something Rust gets right, IMO. If I want the callee and the caller to share mutable ownership, RefCell<T> or Mutex<T> can be used, and the usage of such a type makes that clear. If I want thread safety, I can wrap the mutex in an Arc<T>. And, if I don't want shared ownership, a plain T can be used, and ownership passes into the callee. The issue is: in C#, without defensive measures, all objects are just T* with no ownership or thread-safety.