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=============

Andrew Fedoniouk wrote:

> ==test.d================
> static int v = 0;
> 
> int something(int vv)
> {
>   v = vv;
> }
> 
> int main(char[][] args)
> {
>   something(28);
> }
> 
> ==test.d==EOF============= 

Here's what I get with GDC 0.10:

> test.d:3: function test.something function expected to return a value of type int
> test.d:8: function test.main function expected to return a value of type int

--anders

You are extremely lucky as.

    dmd.exe test.d

is just silently enjoying compilation of this.

Andrew.


"Anders F Björklund" <afb@algonet.se> wrote in message news:d17m4a$298h$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>
>> ==test.d================
>> static int v = 0;
>>
>> int something(int vv)
>> {
>>   v = vv;
>> }
>>
>> int main(char[][] args)
>> {
>>   something(28);
>> }
>>
>> ==test.d==EOF=============
>
> Here's what I get with GDC 0.10:
>
>> test.d:3: function test.something function expected to return a value of
>> type int
>> test.d:8: function test.main function expected to return a value of type
>> int
>
> --anders

On Tue, 15 Mar 2005 13:58:10 -0800, Andrew Fedoniouk <news@terrainformatica.com> wrote:
> 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.

See:
http://www.digitalmars.com/d/archives/digitalmars/D/bugs/1553.html

It's the same/very similar reasoning as the assert in the switch statement.

The compier cannot know your intent, throwing the assert forces you to consider your intent and make it clear in the code so as the compiler (and next programmer to look at it) knows for sure what you intend.

Regan

> The compier cannot know your intent, throwing the assert forces you to consider your intent and make it clear in the code so as the compiler (and next programmer to look at it) knows for sure what you intend.

Agreed, it is very reasonable.

"no return value" should not be a warning but
ruther just an error. Right?

As I understand assertion in runtime is
sort of atavism at these stage of the compiler.


Andrew.



"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsno9iqp723k2f5@nrage.netwin.co.nz...
> On Tue, 15 Mar 2005 13:58:10 -0800, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>> 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.
>
> See: http://www.digitalmars.com/d/archives/digitalmars/D/bugs/1553.html
>
> It's the same/very similar reasoning as the assert in the switch statement.
>
> The compier cannot know your intent, throwing the assert forces you to consider your intent and make it clear in the code so as the compiler (and next programmer to look at it) knows for sure what you intend.
>
> Regan

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.

"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=============
>
>

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=============
>>
>>
>
>

> 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 ?  Im not familiar with compiler internals but wouldn't it have to inject an assert there when generating code ?  If thats the case then it should be easy to switch to a compile time error maybe ?




"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=============
> >>
> >>
> >
> >
>

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=============
>> >>
>> >>
>> >
>> >
>>
>
>

On Tue, 15 Mar 2005 14:41:26 -0800, Andrew Fedoniouk <news@terrainformatica.com> wrote:

>> The compier cannot know your intent, throwing the assert forces you to
>> consider your intent and make it clear in the code so as the compiler (and
>> next programmer to look at it) knows for sure what you intend.
>
> Agreed, it is very reasonable.
>
> "no return value" should not be a warning but
> ruther just an error. Right?

Yes.

> As I understand assertion in runtime is
> sort of atavism at these stage of the compiler.

The runtime assert is given because detecting this at compile time is either very difficult or perhaps impossible in some situations. So, if you were used to it giving an error at compile time, then happened to have one that it could not (or did not yet) detect, you would not know it, and the bug it caused would manifest later in the code, and be hard to track/find.

Throwing the assert tells you exactly where and when the bug occured, allowing you to resolve it quickly and easily.

Regan

> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsno9iqp723k2f5@nrage.netwin.co.nz...
>> On Tue, 15 Mar 2005 13:58:10 -0800, Andrew Fedoniouk
>> <news@terrainformatica.com> wrote:
>>> 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.
>>
>> See:
>> http://www.digitalmars.com/d/archives/digitalmars/D/bugs/1553.html
>>
>> It's the same/very similar reasoning as the assert in the switch
>> statement.
>>
>> The compier cannot know your intent, throwing the assert forces you to
>> consider your intent and make it clear in the code so as the compiler (and
>> next programmer to look at it) knows for sure what you intend.
>>
>> Regan
>
>