-
Notifications
You must be signed in to change notification settings - Fork 10
Changes
This is not a full list by any means. Just few examples to give an impression where the project is directed to.
Volt maintains D position that safe, reliable memory management with garbage collector support is a good default starting point. However, contrary to D, one of most important goals for Volt is to make sidestepping from those defaults as simple and convenient as possible with variety of tools to have a tight control of application memory management.
Volt already have a per thread local allocator delegate that handles all allocations made from a thread: see here and here. All automatic allocations, of course. It can be supplied from application code without and rt modifications.
Inbuilt alloca support for arrays. Ability to supply custom allocator inline with built-in allocation primitives (new). Compiler attribute similar to @nogc proposed for D or some similar tool to enforce specific memory management pattern within some parts of the code. Watt
Volt’s standard library, Watt, has a basic design goal to not make any hidden heap allocations on its own.
Volt TypeInfo's are designed to be small and unlike D doesn't hold onto all of the static functions of classes nor have TypeInfo’s of all of the fields of the types, and could be made smaller if needed with a compiler option --mini-rtti which would make a TypeInfo size on magnitude of several dozens of bytes somewhat limiting their capabilities. Object file generation
All type qualifiers are mangled to preserve type system guarantees between binary boundaries. Strict rules are planned to determine what symbols may be exported from resulting binary, what needs to be emitted to object file and what has internal linkage. For example, templates are planned to have internal linkage by default and can be completely eliminated by compiler if needed, reducing possible binary bloat.