Hi Rust team! First of all, congratulations on the 0.3 release! I have a bikeshed proposal to selectively simplify Rust's syntax in a way that has the side benefit of applying "negative syntactic pressure" on expensive constructs. It boils down to this: remove all special syntax for heap allocations and heap pointers. Keep special syntax for borrowed pointers, keep special syntax for fixed size vectors. E.g. a heap pointer might be ptr<T>. Allocating a block of uninitialized memory of type T might be heap_alloc<T>(), with the normal literals used to initialize it.
Now, this sounds a bit crazy, and I'm pretty sure it won't be adopted, but I'd appreciate it if you gave it a moment's serious consideration and thought about what the impact would really be. I don't think it would cost as much as you might initially think (modern C++ does essentially this with all the shared_ptr etc., and many of the actual allocation calls are hidden behind constructor functions anyway) and there are strong wins. The two main benefits would be: 1. Reduce the complexity of the syntax. In particular, reduce the amount of "special symbols". You've all heard jokes about Perl looking like line-noise, I'm sure. Reducing the amount of special characters you need to know about before understanding code is a win. 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"? Even more importantly, it would make it easier to see what a complicated type means because it would follow simple nesting rules that you already understand, because it's the same rules that apply to user-defined types. It would also make library-pointer types look like the "real thing" (e.g. arc<T>). 2. Apply selective negative pressure to constructs which should be avoided if possible. IMO good syntax makes "preferable" constructs easy to write, and non-preferable constructs harder. Rust does a pretty good job here already (e.g. sharing mutable memory between tasks is suitably clunky). I personally think that heap allocations deserve to be in the "non-preferable" category, too. They add memory management overhead (GC/refcounting). They reduce locality. They add waste (header words, the pointer itself, maybe ref counts, etc.). They increase fragmentation. I believe controlling allocations will be essential to good performance in the future, as heap sizes grow massive (esp. for GC which is O(live_objects)). Heap allocations are absolutely essential sometimes, of course, but it's preferable by far to try to store the data on the stack or interior to the owning data structure, or in a big memory pool, and use borrowed pointers to access it indirectly - only resort to heap pointers if there is no other option. This is also why I think the *only* syntactically preferred pointer should be the borrowed pointer. IMO, Rust makes it far too easy to allocate memory on various heaps - just add a little sigil and you're done. C makes you appreciate the implications of what you're about to do when you type "malloc". Anyway, as I said, I don't think this will gain much traction, but it's one of those small niggles that I would do differently if I was designing the language, so I thought I'd float it for consideration. Thanks for your time! -- Sebastian Sylvan _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
