I just came back to http://www.digitalmars.com/d/abi.html and saw, that there have been no recent changes. I wonder, if this is the current state or if there has been further development on the topic.

If not I'd like to make a few suggestions

Describe memory offsets in multiples of the plattforms native
pointer size (i.e. sizeof(ptrsize_t)). Currently the ABI is
limited to 32 bit. (One might double the sizes implicitly for 64
bit plattforms).

Separate the ABI in Compile Level and Link Level.
The Compile Level operates on the alignment of data within memory
and the data transfer methods within a compilation object.
The Link Level however should be coupled to the output format
(COFF, ELF, $whatever). IMHO it makes sense so describe Link
Level ABI for different object formats.
E.g. the component system I've developed for my engine, called
ECS, similair to DDL, stores the properties of code objects in a
hierachical, EMBF like (EMBF a binary XML counterpart) structure
without elude to name mangling and other tricks. Since ECS
provides a sound set of the runtime code that would otherwise
call statical constructors (and module inits) it also conflicts
a bit with parts of any ABI that would force strict rules on
that topic. Since static constructor calling and module
initialization is part of the Link Level, logically put it
there. Link systems that differ from the usual ELF/PE/COFF will
not by inflicted that way.

Currently declaring a class $xxx implicitly instanciates a Class$xxx, StaticClass$xxx and an instance that names Static$xxx. I wonder if there could be a less namespace polluting solution to that. Maybe somee new properties on the modulespace?

I'm nearly done converting all the C++ source code of my 3D engine to D. Where converting means: "puting nearly 20% of the code to /dev/null". I just love D!!!

-- 
Wolfgang Draxinger