DIP1001: DoExpression

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Wed Sep 7 14:26:45 PDT 2016


On 07.09.2016 14:19, Marc Schütz wrote:
> On Tuesday, 6 September 2016 at 17:01:28 UTC, Timon Gehr wrote:
>> There can be no field (or variables) of type 'void'. (void,void,T) has
>> two fields of type 'void'.
>>
>> Just fixing the limitations is also not really possible, as e.g. void*
>> and void[] exploit that 'void' is special and have a non-compositional
>> meaning.
>
> Out of interest: What's the matter here?

Well, maybe you are right and this should be done as far as possible, 
but the type should not have been overloaded in the first place.

AFAIU it's called void because the C designers intended that there 
should be no value of type void. But a function that returns a value of 
a type that does not have any values cannot return at all. Instead it 
should have precisely one value, which means that values of the type 
carry no information.

Making 'void' an unit type to the extent possible is probably better 
than what we have now, but void* and void[] would become even more weird 
than they are now.

> Can't `void` just get a size of
> 1 byte?

void.sizeof is 1, but void.init is invalid.

> Or is there a problem with `void*` being a super type of any
> pointer type?

It occupies syntax that should have a different meaning.

void[] x = [123456789];
void y = x[0];
void z = x[1];

assert(y==z); // ???

void foo(){}

auto a=[foo()];
void v=a[0];

> The same wouldn't need to apply to `void` itself, AFAICS.

Well, no, but there is no non-breaking way to get rid of the 
non-compositional meaning of void* and void[]. I.e. you can "fix" void 
up to the point where you want to e.g. allow building an array of voids.



More information about the Digitalmars-d mailing list