www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feature Request: make void a value type

reply downs <default_357-line yahoo.de> writes:
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
Dec 03 2007
next sibling parent reply Matti Niemenmaa <see_signature for.real.address> writes:
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
Dec 03 2007
parent downs <default_357-line yahoo.de> writes:
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
Dec 03 2007
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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; }
}
Dec 03 2007
parent reply downs <default_357-line yahoo.de> writes:
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
Dec 03 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Dec 03 2007
parent reply downs <default_357-line yahoo.de> writes:
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
Dec 03 2007
parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
downs wrote:

 Jarrett Billingsley wrote:

 You need to try things!





 void g()
 {
     return f();
 }





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


It was added in D 0.91 in 2004.

-- 
Oskar
Dec 03 2007
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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.
Dec 03 2007
parent reply downs <default_357-line yahoo.de> writes:
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
Dec 03 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Dec 03 2007