At the moment this enhancement proposal is not fully fleshed out, but it's a starting point for future discussions.

Perhaps it can be useful to support a syntax like:


void foo(align(4) ubyte[] buf) {}
void bar(align(16) double[] arr) {}


In a debug build it performs a run-time test that the .ptr field is aligned to 4 or 16 bytes. This is very handy for many situations, including functions that need to work with the CPU SIMD registers.

It's equivalent to code like:

void bar(double[] arr)
in {
    assert(arr.ptr % 16 == 0);
} body {}


But ideally the D type system should carry around the "align(4)" information at compile-time as an optional part of the type of an array (and avoid some of those compile-time tests). Once this information is an optional part of the type of an array, a templated function can tell apart the two cases:

void bar(double[] arr) if (__traits(alignof, arr) == 16) {}
void bar(double[] arr) if (__traits(alignof, arr) != 16) {}

If an array type doesn't have a specified alignment, it is assumed to have the natural alignment of the type it contains.

I think that in a statically type system language a compile-time knowledge of the alignment of a pointer or array is a very valuable information in many cases. I find it strange that in D you can use int[5] to express the idea of a compile-time knowledge of an array of 5 ints, but you can't express the alignment of the data using the built-in type system of D.