This is literally the first day I've tried writing things in D.  I noticed something peculiar.  This program compiles, even though I didn't think it would:

--
int returnInt()
	{
	}

int main()
	{
	printf("got %d\n", returnInt());
	}
--

I expected to get a compile-time error that "not all control paths return a value", or words to that effect.  But, no, it compiles, and throws an AssertionFailure() on line 3 (the ending curly brace for returnInt()).

Is that by design?

By the way, I am enjoying the nigh-instantaneous compile speeds of D.  I have often taken umbrage at how slow MSVC++ is, particularly in Debug mode.  D's compiler is faster than, well, than I *deserve*, probably.

Cheers,


--
/larry/

Larry Hastings wrote:
> 
> 
> This is literally the first day I've tried writing things in D.  I noticed something peculiar.  This program compiles, even though I didn't think it would:
> 
> -- 
> int returnInt()
>     {
>     }
> 
> int main()
>     {
>     printf("got %d\n", returnInt());
>     }
> -- 
> 
> I expected to get a compile-time error that "not all control paths return a value", or words to that effect.  But, no, it compiles, and throws an AssertionFailure() on line 3 (the ending curly brace for returnInt()).
> 
> Is that by design?
> 
> By the way, I am enjoying the nigh-instantaneous compile speeds of D.  I have often taken umbrage at how slow MSVC++ is, particularly in Debug mode.  D's compiler is faster than, well, than I *deserve*, probably.
> 
> Cheers,
> 
> 
> -- 
> /larry/


Turn on the -w option, and you'll get a warning message.

There have been several long, drawn out, battles over that one :-)

Nowadays, the compiler inserts a HALT statement instead of asserting (at least, it does on the Win32 platform).



"Larry Hastings" <larry@hastings.org> wrote in message news:d3q03i$1nar$1@digitaldaemon.com...
>
>
> This is literally the first day I've tried writing things in D.  I noticed something peculiar.  This program compiles, even though I didn't think it would:
>
> --
> int returnInt()
> {
> }
>
> int main()
> {
> printf("got %d\n", returnInt());
> }
> --
>
> I expected to get a compile-time error that "not all control paths
> return a value", or words to that effect.  But, no, it compiles, and
> throws an AssertionFailure() on line 3 (the ending curly brace for
> returnInt()).
>
> Is that by design?
>
> By the way, I am enjoying the nigh-instantaneous compile speeds of D.  I have often taken umbrage at how slow MSVC++ is, particularly in Debug mode.  D's compiler is faster than, well, than I *deserve*, probably.
>
> Cheers,
>
>
> --
> /larry/

On Fri, 15 Apr 2005 20:17:07 -0700, Larry Hastings <larry@hastings.org> wrote:
> This is literally the first day I've tried writing things in D.  I noticed something peculiar.  This program compiles, even though I didn't think it would:
>
> --
> int returnInt()
> 	{
> 	}
>
> int main()
> 	{
> 	printf("got %d\n", returnInt());
> 	}
> --
>
> I expected to get a compile-time error that "not all control paths return a value", or words to that effect.  But, no, it compiles, and throws an AssertionFailure() on line 3 (the ending curly brace for returnInt()).
>
> Is that by design?

Yes.

It all comes back to the fact that D does not have warnings. (actually it does now, but my impression is that they're there on a trial basis only).

http://www.digitalmars.com/d/overview.html

"No Warnings
D compilers will not generate warnings for questionable code. Code will either be acceptable to the compiler or it will not be. This will eliminate any debate about which warnings are valid errors and which are not, and any debate about what to do with them. The need for compiler warnings is symptomatic of poor language design."

Because you cannot know with 100% surety in all cases that a missing return is an error, i.e. code execution will ever leave the function via the missing return statement, you cannot give an error.

Yes, in your example you do know, but in others it's less obvious, eg.

int foo(int val) {
  if (val != 0) return val;
}

it's possible that 'val' never has the value 0 in the program this is used.

So, DMD inserts an assert statement at the end of the function, if code execution does get there it will assert, as you've found.

This behaviour is one of the "hot topics" on these news groups.

Regan

"Kris" <fu@bar.com> wrote in message news:d3q171$1nvq$1@digitaldaemon.com...
> Nowadays, the compiler inserts a HALT statement instead of asserting (at least, it does on the Win32 platform).

In only inserts a HLT in -release mode. Otherwise, the assert is there.

zwang wrote:
> Larry Hastings wrote:
>> This is literally the first day I've tried writing things in D.  I noticed something peculiar.  This program compiles, even though I didn't think it would:
>>
>> -- 
>> int returnInt()
>>     {
>>     }
<snip>
> Turn on the -w option, and you'll get a warning message.

But if there's no return at all, it's supposed to be an error.  The warning is only for if some but not all paths through the function return.  The only situation in which it can make sense to have no returns in such a function is if all routes through it throw an exception or a literal assert(false).

It used to work, to the extent that it would complain if there's no return statement (but regardless of any throws or asserts).  It certainly shouldn't slip through if there are no returns, throws or assert(false) at all!

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.