Zero-length static array spec

via Digitalmars-d digitalmars-d at puremagic.com
Fri Feb 27 02:44:34 PST 2015


On Thursday, 26 February 2015 at 23:17:29 UTC, kinke wrote:
>> 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.

D has `.offsetof`.

>
> 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