mozilla/rust — Issue #1693: Stack-allocation only subset/specifier
Author: litghost
Created: 2012-01-28 16:28:55+00:00
State: open

There are platforms and libraries where allowing Rust to allocate freely from the heap using malloc/free is not the right thing to do. Does it make sense to ensure that the core language of Rust can be used under such conditions? At this point the biggest change is re-vamping vectors to be declared in stack context and in the same way that the rest of the core types can be.

Two motivating examples I can think of are libraries that take allocation functions like zlib (which take an allocation interface) and any time targeting micro-controllers like PICs or AVRs.

Writing the equivalent of of zlib in Rust would require that you avoid vectors and rely on wrapping allocations from the allocator functions in something like c_vec. For fixed size arrays on the size order of 1-32 elements, does it really make sense to require a heap allocation, instead of just grabbing some stack space?

In the case of micro-controllers, I guess there is the question of intentions for the language. Rust explicitly has Win32, Mac, and Linux on the list of primary platforms. However many parts of the language do not require full heap-allocated support. If you avoid shared boxes (which is probably what you would end up doing on micro-controller anyways), the biggest obstacle is the heap allocation for vectors. Requiring heap allocation for vectors completely excludes a large set of Rust programs from being practical on micro-controllers, where-as simply having a stack length immutable/mutable array would suddenly allow a good set of micro-controller programs to be possible.

The title also has the "specifier" bit, because I am wondering if it makes sense to be able to say to the compiler "this function should exist on the stack, warn/error me if you are going to do some heap allocation here". This would be in an effort to allow the compiler to be explicit about "magic" allocations.