Regardless of whether manual memory management is desirable as an end goal, support for it is essentially required if you wish to permit tasks to exchange ownership of data without copies.  For example, in Servo we have a double-buffered system where mutable memory buffers are exchanged between the various parts of the system.  In order to make this safe, we have to guarantee that this buffer is unaliased at the point where it is sent—if you know it's unaliased, of course, you also know that you could safely free it. 

As a broader point, it turns out there are a LOT of type system things you can do if you know something about aliasing (or the lack thereof). Our current approach to freezing data structures for example is reliant on this.  Safe array splitting for data parallelism—if we ever go in that direction—will be reliant on this.  And so forth.  So, supporting a unique-pointer-like construct makes a lot of sense.


Niko

October 28, 2012 4:55 AM
Does make sense to have a language with manual memory management since it's possible to create stuff of low level with a specialized garbage collector?
It's good to create drivers, but it's already C.


i.e. Both Native Oberon and Blue Bottle operating systems were implemented in languages, Oberon and Active Oberon, which have type safety and concurrent (at least in compiler ulm oberon) GC support.

http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pdf


Then, Java is being used in embedded and real-time systems with a deterministic garbage collection:

http://www.pr.com/press-release/226895
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to