-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://digitalmars.com/d/statement.html#return
# Expression is allowed even if the function specifies a void return type.
# The Expression will be evaluated, but nothing will be returned.

return_01.d:
# int dummyJob;
#
# int dummy(){ return ++dummyJob; }
#
# void test(){ return dummy(); }
#
# int main(){
#        test();
#        return dummyJob-1;
# }

> cannot implicitly convert expression dummy() of type int to void

test case:
http://svn.kuehne.cn/dstress/run/return_01.d

Thomas

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.9.13 (GNU/Linux)

iD8DBQFBuAKf3w+/yD4P9tIRAkgkAKCHGuKCjlfCHCqr/BsrzWCwZtp06QCgwzXj
HpgFpl2Jv4TkX2FFl4EQA5w=
=TvmZ
-----END PGP SIGNATURE-----

On Thu, 9 Dec 2004 08:45:37 +0100, Thomas Kuehne <thomas-dloop@kuehne.thisisspam.cn> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> http://digitalmars.com/d/statement.html#return
> # Expression is allowed even if the function specifies a void return type.
> # The Expression will be evaluated, but nothing will be returned.
>
> return_01.d:
> # int dummyJob;
> #
> # int dummy(){ return ++dummyJob; }
> #
> # void test(){ return dummy(); }
> #
> # int main(){
> #        test();
> #        return dummyJob-1;
> # }
>
>> cannot implicitly convert expression dummy() of type int to void
>
> test case:
> http://svn.kuehne.cn/dstress/run/return_01.d
>
> Thomas
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.9.13 (GNU/Linux)
>
> iD8DBQFBuAKf3w+/yD4P9tIRAkgkAKCHGuKCjlfCHCqr/BsrzWCwZtp06QCgwzXj
> HpgFpl2Jv4TkX2FFl4EQA5w=
> =TvmZ
> -----END PGP SIGNATURE-----

Suppose that depends on whether you think the doc or the code is in error there.
(Why would you need to evaluate an expression (pun-roll, please) expressly in a
return statement?)

-- 
"Unhappy Microsoft customers have a funny way of becoming Linux,
Salesforce.com and Oracle customers." - www.microsoft-watch.com:
"The Year in Review: Microsoft Opens Up"
--
"I plan on at least one critical patch every month, and I haven't been disappointed."
- Adam Hansen, manager of security at Sonnenschein Nath & Rosenthal LLP
(Quote from http://www.eweek.com/article2/0,1759,1736104,00.asp)
--
"It's been a challenge to "reteach or retrain" Web users to pay for content, said Pizey"
-Wired website: "The Incredible Shrinking Comic"

Hi..

>> http://digitalmars.com/d/statement.html#return
>> # Expression is allowed even if the function specifies a void return
>> type.
>> # The Expression will be evaluated, but nothing will be returned.

[...]

>>> cannot implicitly convert expression dummy() of type int to void

[...]

> Suppose that depends on whether you think the doc or the code is in error there.

I agree. I think the type should still match, so you can do "return some_func_that_returns_void();" in a function returning void, which feels like it should be allowed since that return wants void and the called function returns void.

> (Why would you need to evaluate an expression (pun-roll, please) expressly in a return statement?)

To eliminate an extra pair of braces:

if (sometest)
    return do_something();

instead of:

if (sometest) {
    do_something();
    return;
}

(I for one like D's behaviour.)

-- 
L.

-- Get the root certificate at https://www.cacert.org/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Simon Buchan schrieb am Fri, 10 Dec 2004 03:18:07 +1300:
> On Thu, 9 Dec 2004 08:45:37 +0100, Thomas Kuehne
><thomas-dloop@kuehne.thisisspam.cn> wrote:
>
>> http://digitalmars.com/d/statement.html#return
>> # Expression is allowed even if the function specifies a void return
>> type.
>> # The Expression will be evaluated, but nothing will be returned.
>>
>> return_01.d:
>> # int dummyJob;
>> #
>> # int dummy(){ return ++dummyJob; }
>> #
>> # void test(){ return dummy(); }
>> #
>> # int main(){
>> #        test();
>> #        return dummyJob-1;
>> # }
>>
>>> cannot implicitly convert expression dummy() of type int to void
>>
>> test case:
>> http://svn.kuehne.cn/dstress/run/return_01.d

> Suppose that depends on whether you think the doc or the code is in error
> there.
> (Why would you need to evaluate an expression (pun-roll, please) expressly
> in a  return statement?)

I usually would say that the the doc has the highest priority ...
But this rule seems very odd. Unless someone provides me with a valid
reason to keep this, I would suggest to adapt the documentation to the
current implementation.

Thomas



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.9.13 (GNU/Linux)

iD8DBQFBuGPH3w+/yD4P9tIRAuiKAKCT5mHK8n2q3G1A+6Zn6g8upoePpwCg0ULf
Q20vF3Cb0WlT6pQmIxk7lyA=
=8m4O
-----END PGP SIGNATURE-----

In article <cp9nto$d4p$1@digitaldaemon.com>, Lionello Lunesu says...
>
>Hi..
>
>>> http://digitalmars.com/d/statement.html#return
>>> # Expression is allowed even if the function specifies a void return
>>> type.
>>> # The Expression will be evaluated, but nothing will be returned.


To Walter,
In case the doc is gonna be adopted, is 'out (result)' going to be
allowed after such void functions?


[...]

>> (Why would you need to evaluate an expression (pun-roll, please) expressly in a return statement?)
>
>To eliminate an extra pair of braces:
>
>if (sometest)
>    return do_something();
>
>instead of:
>
>if (sometest) {
>    do_something();
>    return;
>}


Maybe it's also useful for contract, huh?
Returning type would be a concern, though.


-tetsuya