void foo() { size_t[3] regs = void; asm { mov regs[1], RAX; } } regs[1] is interpreted as add the offset of regs to 1, i.e. *cast(size_t)((cast(void*)®s + 1). This can already be expressed by one of the following two alternatives. 1[regs] or [regs + 1] I think we should make this syntax an error, it's too easy to confuse with array indexing. In the longterm we might consider to interpret this as array indexing.
The inline assembler uses Intel syntax, and for better or worse, that's what it is. We need to either stick with it, as it is fairly well understood by asm programmers, or use D syntax. Some hybrid in between will be liked by nobody.
Can't we just disallow it, and force people to use 1[regs] or [regs + 1] if they really want the byte offset behavior? The issue is not that Martin and I are not familiar with Intel syntax. It is that the expression is both a valid D expression and AsmBrExp, and without reading the grammar, there is no way of knowing what this will turn out to be. Don't forget that nobody will be able to afford writing it things like regs[1] anyway, because others reading the code could mistake it for the obvious alternative – the meaning that the expression has everywhere else except for asm blocks. D has generally fared well with preventing unexpected behavior by outright disallowing potentially ambiguous constructs (the "if it looks like C, it behaves like C" rule, shadowing, …). I don't see why this approach should not apply here. (feel free to re-close as WONTFIX if you still don't think this merits further discussion)
I wrote a D-Scanner rule for this: void testAsm() { asm { mov RAX, a[1]; } } test.d(4:18)[warn]: This is confusing because it looks like an array index. Rewrite a[1] as [a + 1] to clarify.
Back in the days Borland developed IDEAL mode for TASM, which provided handier, stricter, less ambiguous, more idiomatic syntax. Maybe someone can find its description?