Bug 12033 – align() for array arguments of functions
Status
RESOLVED
Resolution
INVALID
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2014-01-29T08:32:15Z
Last change time
2020-03-21T03:56:36Z
Assigned to
No Owner
Creator
bearophile_hugs
Comments
Comment #0 by bearophile_hugs — 2014-01-29T08:32:15Z
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.
Comment #1 by b2.temp — 2020-02-20T15:53:13Z
This stuff cant work. alignment can only works on real declaration, not parameters. Also the .ptr address is controlled by the GC. The proper way to do that is to use AlignedMallocator + makeArray.