Comment #0 by bearophile_hugs — 2013-03-20T11:10:12Z
enum uint myAlignment = 16;
align(myAlignment) struct Foo {}
void main() {}
DMD 2.063alpha gives:
temp.d(2): Error: positive integer expected, not myAlignment
With this a single compile-time constant change is enough to modify at the same time and in the same way for different CPUs various alignments in the code. It's good to be more DRY and avoid magic constants.
Comment #1 by bearophile_hugs — 2013-05-23T09:58:16Z
*** Issue 10149 has been marked as a duplicate of this issue. ***
Comment #2 by leandro.lucarella — 2014-08-08T14:19:09Z
Removed reject-invalid keyword as the specification indicates the syntax is:
align ( IntegerLiteral )
In Sociomantic, being able to specify a compile-time calculated value to align would be useful to overcome alignment issues with structs with static arrays in them. For example:
---
struct E1
{
byte key;
ubyte[(char[]).sizeof] val;
}
---
E1.key offset: 0LU, E1.val offset: 1LU
This is very impolite to the GC. Trying the same in C, it works the same, and since D defines his alignment specification in terms of the host C compiler, this is technically not a bug but a feature. But a better way to overcome this than manually adding padding bytes between both members would be appreciated (using align(8) is not portable, and starting a version() madness because of this doesn't seem like a good option).
Comment #3 by yebblies — 2014-08-09T18:02:14Z
This is probably not a bad idea. The limitation seems rather arbitrary.
When I implemented deprecated(message) I intentionally made it only take a string literal, to the hassle of having an attribute rely on other declarations' semantic passes. Since then, UDAs have forced us to deal with that anyway.
Some of druntime core.sys.windows.* modules also want this,
Like:
version (Win64) align(8):
else align(4):
One example:
https://issues.dlang.org/show_bug.cgi?id=15547
We could make work-around with string-mixin above.
However, I think this is an essential feature for D.