If you don’t care about safety around the allocations of your particular data type, you can certainly have “unsafe” sections of your code that are responsible for the allocation/deallocation of your data type. In the unsafe code (which can be as little as an expression or as much as a function) you can do anything. The point is that the unsafety is limited to sections of code that can be identified as unsafe and can be identified by something as crude as grep.
If you haven’t yet, I encourage you to read through the http://cliffle.com/p/dangerust/ article. It’s very good, and will demonstrate that in Rust, you can be as crude as C or as safe as Haskell, or anywhere in between - with very fine granularity. ../Dave On Jan 2, 2020, 5:16 PM -0500, Nicholas Krause <[email protected]>, wrote: > > > On 1/2/20 1:57 PM, David Mason wrote: > > On Jan 2, 2020, 11:22 AM -0500, Nicholas Krause <[email protected]>, > > wrote: > > > Thanks for letting me know. Don't know if it will be solved as that's a > > > problem in my view. > > > > I was going to say that you could implement a garbage collector in/for > > Rust, but first I checked if there was a crate for one, and sure enough, > > there is: https://github.com/Manishearth/rust-gc/ for those occasions when > > you really need a garbage collector. It’s in development, but looks pretty > > usable. > > > > ../Dave > This isn't a issue that can be solved by a garbage collector which are > notoriously for having > these leaks but something like a unsafe mode with something similar to > weak_ptr in C++. > > > Not sure what the unsafe Rust implementation would would do but its a > outstanding > issue if you assume that memory has a non circular owner, > > Nick
--- Post to this mailing list [email protected] Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
