current dmd compiles the following function without any warning:

void bar(){ return 9; }

fix for one example in the current phobos sources:

diff -ubBr dmd/src/phobos/internal/object.d neu/src/phobos/internal/object.d
--- dmd/src/phobos/internal/object.d	2004-07-22 13:38:58.000000000 +0200
+++ neu/dmd/src/phobos/internal/object.d	2004-07-31 17:10:41.087019416 +0200
@@ -120,7 +120,7 @@
int equals(void *p1, void *p2) { return base.equals(p1, p2); }
int compare(void *p1, void *p2) { return base.compare(p1, p2); }
int tsize() { return base.tsize(); }
-    void swap(void *p1, void *p2) { return base.swap(p1, p2); }
+    void swap(void *p1, void *p2) { base.swap(p1, p2); }

TypeInfo base;
}

Thomas Kuehne wrote:
> current dmd compiles the following function without any warning:
> 
> void bar(){ return 9; }
> 
> fix for one example in the current phobos sources:
> 
> diff -ubBr dmd/src/phobos/internal/object.d neu/src/phobos/internal/object.d
> --- dmd/src/phobos/internal/object.d	2004-07-22 13:38:58.000000000 +0200
> +++ neu/dmd/src/phobos/internal/object.d	2004-07-31 17:10:41.087019416 +0200
> @@ -120,7 +120,7 @@
> int equals(void *p1, void *p2) { return base.equals(p1, p2); }
> int compare(void *p1, void *p2) { return base.compare(p1, p2); }
> int tsize() { return base.tsize(); }
> -    void swap(void *p1, void *p2) { return base.swap(p1, p2); }
> +    void swap(void *p1, void *p2) { base.swap(p1, p2); }
> 
> TypeInfo base;
> }
> 
> 

It's not a bug, but a (recently included) feature.

Lars Ivar Igesund

Thomas Kuehne wrote:

> current dmd compiles the following function without any warning:
> 
> void bar(){ return 9; }

As I understand it, everything can be implicitly converted to void. It's useful for template functions where the return type is not known.

It does seem kind of shady, but I can't recall ever being bitten by it, nor can I think of a situation where it could easily happen by accident.

 -- andy

>> current dmd compiles the following function without any warning:
>> 
>> void bar(){ return 9; }
>
>As I understand it, everything can be implicitly converted to void. It's useful for template functions where the return type is not known.
>
>It does seem kind of shady, but I can't recall ever being bitten by it, nor can I think of a situation where it could easily happen by accident.

I'could understand this if it would be: void* bar(){ return 9; }

Looking through the generated object code / assembler there seems to be NO return of the value nor a pointer to it?

Thomas

"Lars Ivar Igesund" <larsivar@igesund.net> wrote in message news:cegkng$16e3$1@digitaldaemon.com...
> Thomas Kuehne wrote:
> > current dmd compiles the following function without any warning:
> >
> > void bar(){ return 9; }
> >
> > fix for one example in the current phobos sources:
> >
> > diff -ubBr dmd/src/phobos/internal/object.d neu/src/phobos/internal/object.d
> > --- dmd/src/phobos/internal/object.d 2004-07-22 13:38:58.000000000 +0200
> > +++ neu/dmd/src/phobos/internal/object.d 2004-07-31 17:10:41.087019416 +0200
> > @@ -120,7 +120,7 @@
> > int equals(void *p1, void *p2) { return base.equals(p1, p2); }
> > int compare(void *p1, void *p2) { return base.compare(p1, p2); }
> > int tsize() { return base.tsize(); }
> > -    void swap(void *p1, void *p2) { return base.swap(p1, p2); }
> > +    void swap(void *p1, void *p2) { base.swap(p1, p2); }
> >
> > TypeInfo base;
> > }
> >
> >
>
> It's not a bug, but a (recently included) feature.
>
> Lars Ivar Igesund

I didn't realise that it allowed that though. I think that's bad.

I was assuming it would facilitate something like the following, and no more:

    void f1()
    {
        ;
    }

    void f2()
    {
        return f1();
    }

or

    void f2(void function() f)
    {
        return f;
    }

Anything more than that is wrong, IMO, unless someone can demonstrate a need to support other generics requirements

Matthew wrote:
> 
> I didn't realise that it allowed that though. I think that's bad.
> 
> I was assuming it would facilitate something like the following, and no more:
> 
>     void f1()
>     {
>         ;
>     }
> 
>     void f2()
>     {
>         return f1();
>     }
> 
> or
> 
>     void f2(void function() f)
>     {
>         return f;
>     }
> 
> Anything more than that is wrong, IMO, unless someone can demonstrate a need to support other generics requirements

I agree.  Being able to "return void" in a void function is important, but I don't see being able to "return 9" in a void function as anything other than an error.  Can someone think of a template example where this might actually be useful behavior?


Sean

In article <cehu4m$1nsl$1@digitaldaemon.com>, Matthew says...

>I didn't realise that it allowed that though. I think that's bad.
>
>I was assuming it would facilitate something like the following, and no more:
>
>    void f1()
>    {
>        ;
>    }
>
>    void f2()
>    {
>        return f1();
>    }
>
>or
>
>    void f2(void function() f)
>    {
>        return f;
>    }
>
>Anything more than that is wrong, IMO, unless someone can demonstrate a need to support other generics requirements

Just to make a change, I completely agree with Matthew on all counts.

Someone said that all types can be cast to void. That may be true, but please note that casting something to void is a /narrowing/ conversion (i.e. convertings /some/ information to /none/). Accordingly, conversion of a type to void should require an explicit cast. I don't see why the compiler shouldn't detect the lack of this, and turn current behavior into a compile-error, as Matthew and I would like.

Arcane Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cejdot$2aj2$1@digitaldaemon.com...
> In article <cehu4m$1nsl$1@digitaldaemon.com>, Matthew says...
>
> >I didn't realise that it allowed that though. I think that's bad.
> >
> >I was assuming it would facilitate something like the following, and no more:
> >
> >    void f1()
> >    {
> >        ;
> >    }
> >
> >    void f2()
> >    {
> >        return f1();
> >    }
> >
> >or
> >
> >    void f2(void function() f)
> >    {
> >        return f;
> >    }
> >
> >Anything more than that is wrong, IMO, unless someone can demonstrate a need to support other generics requirements
>
> Just to make a change, I completely agree with Matthew on all counts.

Yawn. You're not the first to make things personal with me, just because I've (strongly) criticised your opinions. I can't comprehend this attitude. If I called you an arsehole, then I'd accept that things had "got personal", but I'm pretty sure I have not done so. I have taken issue with some of your notions, that's all. The fact that you agree with me on one thing, and not on others does not make a whit of difference to any personal relationship we have, since we have none. This is just faceless posting to a NG. I'm sure if we met in person that we'd get on fine, since I don't judge people on their technical opinions (otherwise I'd dislike every software engineer I'd ever met), rather I'm interested in their character. From what miniscule insights into your character I've been able to make on the NG, it seems perfectly fine.

Sigh. Now I'm wondering why I just didn't do a Walter, and be a duck's back to your water. (Well, I type really quickly, so it was only a few seconds.) :-)

> Someone said that all types can be cast to void. That may be true, but please note that casting something to void is a /narrowing/ conversion (i.e. convertings /some/ information to /none/). Accordingly, conversion of a type to void should require an explicit cast. I don't see why the compiler shouldn't detect the lack of this, and turn current behavior into a compile-error, as Matthew and I would like.
>
> Arcane Jill
>
>
>

"Now I'm wondering why I just didn't do a Walter, and be a duck's back to your water"

i'm wondering that as well, as Jill's comment seemed (to me) to be harmless
;)