On Fri, Jul 13, 2012 at 5:18 PM, Graydon Hoare <gray...@mozilla.com> wrote: > > Thus ~T becomes uniq<T>, ~expr becomes uniq(expr), etc? >
Yep. > >> Allocating a block of >> uninitialized memory of type T might be heap_alloc<T>(), with the >> normal literals used to initialize it. > > > Note: we don't support allocating uninitialized memory. Sure, the heap_alloc could take the initial value as input and do whatever optimizations needed to make sure it never actually creates the literal on the stack just to copy it to the heap. >> Getting rid >> of some of the symbols and treating those types in a more regular way >> would also kill a lot of design problems like "what does a heap >> allocated fixed-sized vector literal look like"? > > > Unless you're planning on making our type parameters carry integer types -- > danger! -- this proposal doesn't help there. > Well vectors would retain their special syntax (fixed size arrays are pure goodness and should be syntactically preferred) so the size would be part of the vector type/literal. The point is that figuring out what a pointer to T looks like is easy (on both the type and constructor side), even if T is one of the special forms like vectors. It seems to me that you get into more head-aches when you need to figure out how to make multiple special forms of syntax interact nicely and without surprising people. > Yeah. Again, this is in tension with "letting users write what they need > to". Rust initially prohibited even _cyclic_ memory and made all private > memory copy-on-write. Guess what was the first and most pressing request? Sure, but as for allocations I think we have more experience about the benefits and dangers of making it pretty. Not necessarily in the way of having 100% analogous languages, but in the way of being able to look at languages that make heap allocation very common, and languages that make it a big deal. I agree with you that it may not be completely clear where Rust stands in this spectrum yet since it's sort of a psychological thing, but I think we can at least say that in general languages that make allocations ugly have done a better job at avoiding that particular performance pitfall in practice. Perhaps Rust's more robust support for interior data (compared to Lua or whatever) is enough, but if you can make allocations stick out even more while simultaneously simplifying the syntax then it may add up to being a good idea. Seb -- Sebastian Sylvan _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
