Charles wrote:
> Yea we've been trying to get Walter to make this a compile time error
> forever, he stands alone on the 'shut-up code' argument last I read.
> 
> Can anyone give me a situation where no return is NOT an error, and
> therefore should not be caught at compile time ?  I'd even go further and
> say 'not-all control paths return a value' should be a compile time error.

Well, as far as I am concerned, Walter does have a point, although it still could check whether there is any return statement at all (like in OP's case), and produce an error in the case there isn't.

As for the example of where it's not an error:

Something[] things;
Something get(int id)
{
    int pos=0;
    for (int a=0; a<things.length; a++)
        if (things[a].id==id) {
            return things[a];
        } else
        if (things[a] is null) {
            return (things[a]=new Something(id));
        }
}


Now, when the compiler sees this it will figure that the for loop can end, and there is no return after it. I, however, know that things[] is always long enough to contain a null and so the error will never happen.

OTOH, if I put "return null" at the end just to silence the compiler, if there is actually a bug and things[] doesn't contain a null, I won't get the error here, where I should, but somewhere else, and it will also be the wrong error "someVar is null" instead of "things[] didn't contain a null"..


xs0

"Andrew Fedoniouk" <news@terrainformatica.com> wrote:

[...]
> IMO, either this code must not compile at all or
> flag -w (warnings) should be 'on' by default.
[...]

Please describe an _algorithm_ that checks reliably for variables not initialized during runtime, because not having a `return' processed in a function during runtime is the same as leaving the implicit return value uninitialized.

Otherwise just turn -w on for ever, if you want the compiler to nitpick on your code.

-manfred

xs0 wrote:
> Charles wrote:
> 
>> Yea we've been trying to get Walter to make this a compile time error
>> forever, he stands alone on the 'shut-up code' argument last I read.
>>
>> Can anyone give me a situation where no return is NOT an error, and
>> therefore should not be caught at compile time ?  I'd even go further and
>> say 'not-all control paths return a value' should be a compile time error.
> 
> 
> Well, as far as I am concerned, Walter does have a point, although it still could check whether there is any return statement at all (like in OP's case), and produce an error in the case there isn't.
> 
> As for the example of where it's not an error:
> 
> Something[] things;
> Something get(int id)
> {
>     int pos=0;
>     for (int a=0; a<things.length; a++)
>         if (things[a].id==id) {
>             return things[a];
>         } else
>         if (things[a] is null) {
>             return (things[a]=new Something(id));
>         }
> }
> 
> 
> Now, when the compiler sees this it will figure that the for loop can end, and there is no return after it. I, however, know that things[] is always long enough to contain a null and so the error will never happen.
> 
> OTOH, if I put "return null" at the end just to silence the compiler, if there is actually a bug and things[] doesn't contain a null, I won't get the error here, where I should, but somewhere else, and it will also be the wrong error "someVar is null" instead of "things[] didn't contain a null"..

I think the correct way to "shut the compiler up" in this case is to add an "assert(false);" statement to the end of the function.  This lets the compiler know that execution must never reach that point, and, even better, it lets the people reading the code know that execution must never reach that point.

All that's necessary is for DMD's flow analysis stuff to check for assert(false);

 -- andy

> Please describe an _algorithm_ that checks reliably for variables not initialized during runtime, because not having a `return' processed in a function during runtime is the same as leaving the implicit return value uninitialized.

Theoretically such _algorithm_ does exist as each program is just a finite
state automata,
but practically full implementation is not feasible.

D and Java deal with this by assigning implicitly null/0 to all variables
(including return value).
And this is good.

My point is simple: if you can recognize "no return value" situation then this should not be a warning but just an error (which it is).

I understand that for pre-0.117 versions there was only one way to deal with
it -
to place throw ErrorAssert at the end of function body block.
But now this solution is obsolete I guess.

Andrew.


"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:d1952k$s6n$1@digitaldaemon.com...
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote:
>
> [...]
>> IMO, either this code must not compile at all or
>> flag -w (warnings) should be 'on' by default.
> [...]
>
> Please describe an _algorithm_ that checks reliably for variables not initialized during runtime, because not having a `return' processed in a function during runtime is the same as leaving the implicit return value uninitialized.
>
> Otherwise just turn -w on for ever, if you want the compiler to nitpick on your code.
>
> -manfred

"Andrew Fedoniouk" <news@terrainformatica.com> wrote:

> Theoretically such _algorithm_ does exist as each program is
> just a finite state automata,
> but practically full implementation is not feasible.

Agreed, but only because I did not express precisely, what I was talking of.

> D and Java deal with this by assigning implicitly null/0 to all
> variables (including return value).
> And this is good.

But this assignment is done at compile time, while my request was on checking for runtime assignements. But I admit that this might be nitpicking on my words: I wanted to ask for an _algorithm_ that checks if every variable is used at runtime or initialized to some useful value at runtime, thereby considering the value of the automatic initialization as not useful under every circumstances.

Do you admit that the existence of any such _algorithm_ implies a solution to the halting problem?

> My point is simple: if you can recognize "no return value" situation then this should not be a warning but just an error (which it is).
[...]

To issue the warning "no return value at the end of the function" the compiler has to check only the last statement of the function nothing else, and as it has been pointed out in this thread, the missing of such a `return' is not a sure indication for an error.

And if you are content with automatic initializations you shouldn't demand a compile time error instead of a runtime error, but the automatic returning of a default value, if the end of the value returning function is reached.

-manfred

> To issue the warning "no return value at the end of the function" the compiler has to check only the last statement of the function nothing else, and as it has been pointed out in this thread, the missing of such a `return' is not a sure indication for an error.

As far as I can see Walter is already doing analysis of AST
for exit points ( fallOffEnd() method ).
Not sure though - just took a brief look.

So detection of "not all control paths return a value" is already there.

BTW:
  "not all control paths return a value" in C is a warning
and in Java it is an error - will not compile at all.

I cannot see any reasons to go C way here. Do you?

Andrew.


"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:d1af1t$2ce7$1@digitaldaemon.com...
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote:
>
>> Theoretically such _algorithm_ does exist as each program is
>> just a finite state automata,
>> but practically full implementation is not feasible.
>
> Agreed, but only because I did not express precisely, what I was talking of.
>
>> D and Java deal with this by assigning implicitly null/0 to all
>> variables (including return value).
>> And this is good.
>
> But this assignment is done at compile time, while my request was on checking for runtime assignements. But I admit that this might be nitpicking on my words: I wanted to ask for an _algorithm_ that checks if every variable is used at runtime or initialized to some useful value at runtime, thereby considering the value of the automatic initialization as not useful under every circumstances.
>
> Do you admit that the existence of any such _algorithm_ implies a solution to the halting problem?
>
>> My point is simple: if you can recognize "no return value" situation then this should not be a warning but just an error (which it is).
> [...]
>
> To issue the warning "no return value at the end of the function" the compiler has to check only the last statement of the function nothing else, and as it has been pointed out in this thread, the missing of such a `return' is not a sure indication for an error.
>
> And if you are content with automatic initializations you shouldn't demand a compile time error instead of a runtime error, but the automatic returning of a default value, if the end of the value returning function is reached.
>
> -manfred

"Andrew Fedoniouk" <news@terrainformatica.com> wrote:

[...]
> BTW:
>   "not all control paths return a value" in C is a warning
> and in Java it is an error - will not compile at all.
> 
> I cannot see any reasons to go C way here. Do you?

I see at least one reason:
distribution of return statements over several control paths
increases computational complexity.

Reasonings:
increase of computational complexity
---> severe sign for increased needs on human factors in 
understanding the code.
---> sign of reduced maintainability
---> increased costs
---> contradiction to a main goal of the design of D

Although cost reduction is a main goal in the design of D this NG has not evolved any cost model. So I cannot prove in an accepted way the increase of costs by introducing automatic checking of all control paths for the existence of a `return'.

Conclusion: Having more than one return in a function is bad style and the compiler should not support bad style.

-manfred

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

Manfred Nowak schrieb am Thu, 17 Mar 2005 11:54:38 +0000 (UTC):
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote:
>
> [...]
>> BTW:
>>   "not all control paths return a value" in C is a warning
>> and in Java it is an error - will not compile at all.
>> 
>> I cannot see any reasons to go C way here. Do you?
>
> I see at least one reason:
> distribution of return statements over several control paths
> increases computational complexity.
>
> Reasonings:
> increase of computational complexity
> ---> severe sign for increased needs on human factors in 
> understanding the code.
> ---> sign of reduced maintainability
> ---> increased costs
> ---> contradiction to a main goal of the design of D
>
> Although cost reduction is a main goal in the design of D this NG has not evolved any cost model. So I cannot prove in an accepted way the increase of costs by introducing automatic checking of all control paths for the existence of a `return'.
>
> Conclusion: Having more than one return in a function is bad style and the compiler should not support bad style.

Are your working on memory restrained devices? It's the only place where the one-function-one-return style is usefull.

Unless your are solving fairly trivial problems your functions will get some complexity and trying to use one return per function can drastically increase the complexity further(-> goto).

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCOXQR3w+/yD4P9tIRAp1gAKC+7GREhS5N7mGTrAdhX1M4uMTdagCgpnlh
f3rKp18jej4HeazWJusi6j0=
=/vkK
-----END PGP SIGNATURE-----

Manfred Nowak wrote:

> Conclusion: Having more than one return in a function is bad style and the compiler should not support bad style.

I'm not sure that eg. adding a flag variable or using goto is better ?
(being the usual workarounds, for languages with just one return path)

Having several return statements is a very common form to use.... See:
http://www.refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html
http://c2.com/cgi/wiki?GuardClause

Just because it *could* be bad style, does not mean that it always is ?
Sometimes using "return" or "break" is the clearest way of expression.

But I haven't seen many people, except Walter, use gotos beyond 90's :-)

--anders

PS. Pre-condition contracts could be used to check *programmer* params.
    This was just one example of when multiple returns could be useful.

I would prefer this an error as well :).


"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsnpiuwlf23k2f5@nrage.netwin.co.nz...
> On Tue, 15 Mar 2005 19:31:54 -0600, Charles <cee-lo@green.com> wrote:
> >> The problem is not simply whether it's an error or not. It's whether
you
> >> can correctly detect all cases, and the answer seems to be "no, you cannot", or, "you might be able to but it would take a lot of work to
do
> >> so".
> >
> > You mean for the no return statement ?
>
> Yes.
>
> > Im not familiar with compiler
> > internals but wouldn't it have to inject an assert there when generating
> > code ?
>
> Yes. But...
>
> int foo() {
>    if (true) return 5;
> }
>
> the compiler simply injects an assert at the end of this function. We're it to give an error, it would be wrong.
>
> > If thats the case then it should be easy to switch to a compile time error maybe ?
>
> No. Because of false errors, as shown in the example above.
>
> Regan
>
> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsnpibito23k2f5@nrage.netwin.co.nz...
> >> On Tue, 15 Mar 2005 18:18:36 -0600, Charles <cee-lo@green.com> wrote:
> >> > Yea we've been trying to get Walter to make this a compile time error forever, he stands alone on the 'shut-up code' argument last I read.
> >> >
> >> > Can anyone give me a situation where no return is NOT an error, and therefore should not be caught at compile time ?  I'd even go further
> > and
> >> > say 'not-all control paths return a value' should be a compile time error.
> >>
> >> The problem is not simply whether it's an error or not. It's whether
you
> >> can correctly detect all cases, and the answer seems to be "no, you cannot", or, "you might be able to but it would take a lot of work to
do
> >> so".
> >>
> >> It's true that some C/C++ compilers attempt to, they also give false positives, meaning, when you get one you're not sure if it's a real
one,
> >> or not.
> >>
> >> Regan
> >>
> >> > "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d17lpi$291e$1@digitaldaemon.com...
> >> >> Following program, being compiled
> >> >> in -debug,  in runtime ends up with the
> >> >> following:
> >> >>
> >> >> C:\d\test>test.exe
> >> >> Error: AssertError Failure test(8)
> >> >>
> >> >> The source of the problem is in int something() -
> >> >> it does not have renturn value set.
> >> >>
> >> >> IMO, either this code must not compile at all or
> >> >> flag -w (warnings) should be 'on' by default.
> >> >>
> >> >> Andrew.
> >> >>
> >> >> ==test.d================
> >> >> static int v = 0;
> >> >>
> >> >> int something(int vv)
> >> >> {
> >> >>   v = vv;
> >> >> }
> >> >>
> >> >> int main(char[][] args)
> >> >> {
> >> >>   something(28);
> >> >> }
> >> >>
> >> >> ==test.d==EOF=============
> >> >>
> >> >>
> >> >
> >> >
> >>
> >
> >
>