<div dir="ltr">On 28 October 2013 06:50, monarch_dodra <span dir="ltr"><<a href="mailto:monarchdodra@gmail.com" target="_blank">monarchdodra@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sunday, 27 October 2013 at 20:30:05 UTC, Andrei Alexandrescu wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yah, something like that. I found align(NNN) underspecified and underpowered for my work with allocators. As a simple matter, NNN must be a literal, not a compile-time expression. You can't even write e.g. align(size_t.alignof), which is fairly basic.<br>

<br>
<br>
Andrei<br>
</blockquote>
<br></div>
In that case, we also need to specify how alignOf works. For example:<br>
<br>
struct S<br>
{<br>
    align(128) int i;<br>
}<br>
<br>
static assert(S.alignOf == 128);<br>
<br>
If "align(N)" is supposed to only mean "alignement relative to the start of the struct", why the heck is S's "alignOf" 128?<br>
<br>
Also, (but I can't double check it right now), I seem to remember that there are odd things, like "ulong.alignOf == 8", yet if you declare one on the stack, you notice it's only 4 aligned (at least, on my win32 (I think) it is...)<br>

</blockquote></div><br></div><div class="gmail_extra">I had a lot of informal conversations with Walter trying to get my head around the details here.</div><div class="gmail_extra">To my recollection, the intent was that it should behave like C, and that S.alignof must certainly == 128 in that case. It can't work otherwise.</div>
<div class="gmail_extra">Alignment must be inherited by parent structures.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I also recall commenting on that case with ulong. On most architectures it only needs to be 4 byte aligned, but that one is arch specific.</div>
</div>