Zero-length static array spec

kinke via Digitalmars-d digitalmars-d at puremagic.com
Thu Feb 26 15:17:28 PST 2015


> Why's that? Shouldn't _all_ 0 size variables compare equal? I'd 
> say that follows from the definition:
>
>     array1 == array2
>         <=>
>     all corresponding elements of both arrays are equal
>         <=>
>     no corresponding elements of both arrays are different
>
> For the last one, it's obvious that this applies to empty 
> arrays: they don't even contain elements that could compare 
> unequal.

+1.

My proposal: let the front-end handle all 0-sized types in a 
special way. Note that this definition includes:
* zero-length static arrays
* static arrays of 0-sized elements
* structs with no or only 0-sized elements
* void

By definition, instances of these types don't exist physically, 
so no memory should be allocated.
Then, at least to me it feels natural to disallow taking their 
addresses, or, if that's too strict for degenerate templates, to 
define it to be null (the address shouldn't really matter as long 
as the template later reads T.sizeof=0 bytes from that address 
and doesn't use it to compute offsets). I don't think that hacky 
last-element-of-variable-length-struct use-case is worth the 
pain, there's got to be a cleaner solution for that.

Instead, variables of these types represent purely implicit 
symbols.
0-sized static arrays have a compile-time length, their .ptr is 
implicitly defined as null.
0-sized static arrays of corresponding element type are equal as 
long as their lengths match, just like 0-sized structs of 
corresponding type are equal.

The front-end would need to fold all usages of these 0-sized 
variables. It would omit all declared function 
parameters/arguments, return values (=> void) and all other 
variables of size 0 for the different back-ends.


More information about the Digitalmars-d mailing list