Proposal: to allow us to treat void as a value type.
What this would allow:
 * simplifying templates that differ between return type, i.e. static if (is(ReturnType!(C)==void)) param(); else return param();
    I write code like that all the time :(
 * Allowing sets, i.e. void[int] .. this is something many newcomers intuitively expect to work; and by rights, it should.

Problems:
 * With void.sizeof being 0, void is the only type where an array has completely different properties than the original type. I'm not sure whether this really is a problem.

Code this breaks:
 * None that I can see; it only seems to affect situations that would be illegal under the current spec.

What do you think?
 --downs

downs wrote:
> Problems: * With void.sizeof being 0, void is the only type where an array has completely different properties than the original type. I'm not sure whether this really is a problem.

void.sizeof is 1, so there's even less of a problem than you think.

> What do you think?

I've been wanting this for a while and I'd love to see it happen.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi

"downs" <default_357-line@yahoo.de> wrote in message news:fj1cc2$13c3$1@digitalmars.com...
> Proposal: to allow us to treat void as a value type.
> What this would allow:
> * simplifying templates that differ between return type, i.e. static if
> (is(ReturnType!(C)==void)) param(); else return param();

This is already possible.  Return statements with expressions in functions that return void will be evaluated and their results thrown away.

void foo()
{
    return writefln("hi!");
}

is the same as:

void foo()
{
    { writefln("hi!"); return; }
}

Matti Niemenmaa wrote:
> downs wrote:
>> Problems: * With void.sizeof being 0, void is the only type where an array has completely different properties than the original type. I'm not sure whether this really is a problem.
> 
> void.sizeof is 1, so there's even less of a problem than you think.
> 

Okay, but the thing is, I wouldn't want a void variable or parameter or AA entry to take up any space at all. So void.sizeof probably would have to be zero for this to be consistent. Not sure.

>> What do you think?
> 
> I've been wanting this for a while and I'd love to see it happen.
> 

Yay! :D

Jarrett Billingsley wrote:
> "downs" <default_357-line@yahoo.de> wrote in message news:fj1cc2$13c3$1@digitalmars.com...
>> Proposal: to allow us to treat void as a value type.
>> What this would allow:
>> * simplifying templates that differ between return type, i.e. static if
>> (is(ReturnType!(C)==void)) param(); else return param();
> 
> This is already possible.  Return statements with expressions in functions that return void will be evaluated and their results thrown away.
> 
[snip example]

Yes, but what I want is actually being able to _return an expression that *evaluates to void*_. Not the same.
 --downs

downs wrote:
> Proposal: to allow us to treat void as a value type.
> What this would allow:
>  * simplifying templates that differ between return type, i.e. static if (is(ReturnType!(C)==void)) param(); else return param();
>     I write code like that all the time :(
>  * Allowing sets, i.e. void[int] .. this is something many newcomers intuitively expect to work; and by rights, it should.
> 
> Problems:
>  * With void.sizeof being 0, void is the only type where an array has completely different properties than the original type. I'm not sure whether this really is a problem.
> 
> Code this breaks:
>  * None that I can see; it only seems to affect situations that would be illegal under the current spec.
> 
> What do you think?
>  --downs

I did have completely separate ways of proxying void methods versus returning methods, and it was a mess. Ugliness to the core. Right now, I'm replacing it with static ifs, which is bulky and ugly, but it avoids rampant code duplication.

Your suggestion would simplify my code even more. I could eliminate almost all the static ifs, as long as void.init worked.

Christopher Wright wrote:
> I did have completely separate ways of proxying void methods versus returning methods, and it was a mess. Ugliness to the core. Right now, I'm replacing it with static ifs, which is bulky and ugly, but it avoids rampant code duplication.
> 
> Your suggestion would simplify my code even more. I could eliminate almost all the static ifs, as long as void.init worked.

.init is broken in interesting ways for several cases (ever tried typeof((int[4]).init)?)
Try template Init(T) { T Init; } instead. :)
 --downs

"downs" <default_357-line@yahoo.de> wrote in message news:fj1das$150r$1@digitalmars.com...
> Jarrett Billingsley wrote:
>> "downs" <default_357-line@yahoo.de> wrote in message news:fj1cc2$13c3$1@digitalmars.com...
>>> Proposal: to allow us to treat void as a value type.
>>> What this would allow:
>>> * simplifying templates that differ between return type, i.e. static if
>>> (is(ReturnType!(C)==void)) param(); else return param();
>>
>> This is already possible.  Return statements with expressions in
>> functions
>> that return void will be evaluated and their results thrown away.
>>
> [snip example]
>
> Yes, but what I want is actually being able to _return an expression that
> *evaluates to void*_. Not the same.
> --downs

You need to try things!

void f()
{
    writefln("f!");
}

void g()
{
    return f();
}

void main()
{
    g();
}

Works just fine.

"downs" <default_357-line@yahoo.de> wrote in message news:fj1j9d$1elr$1@digitalmars.com...
> Christopher Wright wrote:
>> I did have completely separate ways of proxying void methods versus returning methods, and it was a mess. Ugliness to the core. Right now, I'm replacing it with static ifs, which is bulky and ugly, but it avoids rampant code duplication.
>>
>> Your suggestion would simplify my code even more. I could eliminate almost all the static ifs, as long as void.init worked.
>
> .init is broken in interesting ways for several cases (ever tried
> typeof((int[4]).init)?)
> Try template Init(T) { T Init; } instead. :)
> --downs

That's not actually broken -- the init of a fixed array is the init of its element types.  std.traits actually uses this bizarre inconsistency to determine isStaticArray.

Jarrett Billingsley wrote:
> 
> You need to try things!
> 
> void f()
> {
>     writefln("f!");
> }
> 
> void g()
> {
>     return f();
> }
> 
> void main()
> {
>     g();
> }
> 
> Works just fine.
> 
> 

OMGSQUEE!!!!!
Thanks! I think this used to not work at some point and then got fixed or so but anyway it works! HAPPIES!!
 --happydowns