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