http://d.puremagic.com/bugzilla/show_bug.cgi?id=180

           Summary: DMD accepts a function with a non-void return type but
                    no return statements
           Product: D
           Version: 0.160
          Platform: PC
               URL: http://www.digitalmars.com/d/statement.html#return
        OS/Version: Windows
            Status: NEW
          Keywords: accepts-invalid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: smjg@iname.com


The spec for ReturnStatement states:

"At least one return statement is required if the function specifies a return type that is not void."

However, the compiler fails to honour this requirement, as shown by the most trivial testcase:

----------
int main() {}
----------

Walter has mentioned that there's a reason to allow paths through a function that would walk off the end without returning.

However, there is no reason that a function with a non-void return type should be allowed to have no return statements at all.  The only possible exception is if the function explicitly throws an exception or assert(false), but if either of these is to be allowed instead of a single return statement then the spec would have to be modified to this effect.

As such, the compiler should be reporting an error on such code as the above.


-- 

On Wed, 07 Jun 2006 22:19:47 +1000, <d-bugmail@puremagic.com> wrote:


> As such, the compiler should be reporting an error on such code as the above.

This is one of the 'optional' errors. You can get the compiler to issue an error by using the -w switch.


-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:
> On Wed, 07 Jun 2006 22:19:47 +1000, <d-bugmail@puremagic.com> wrote:
> 
> 
>> As such, the compiler should be reporting an error on such code as the above.
> 
> This is one of the 'optional' errors. You can get the compiler to issue an error by using the -w switch.

I really don't understand why it's optional.
It indicates either: a very common bug (left off a return statement).
or.. a coding documentation bug (having no return is so rare, that it needs a comment in the source code. Why not make the comment an assert(0)?).

To quote warnings.html:

warnings are either a symptom of broken language design or a useful 'lint' like tool to analyze code and look for potential trouble spots. Most of the time, those trouble spots will be legitimate code intended to be that way. More rarely, it may indicate an unintentional error on the part of the programmer.

Leaving off a return statement is not normally legitimate code. It's really easy to do by mistake.

(In contrast, "implicit conversion of expression expr of type type to type can cause loss of data" is almost certainly legitimate code rather than an error).

However, I think the error message should not just be "missing return statement", it should be more like:
"missing return statement, or assert(0) if code is unreachable".

Certainly it should be an error if a function doesn't contain any return statements at all!

Derek Parnell wrote:
> On Wed, 07 Jun 2006 22:19:47 +1000, <d-bugmail@puremagic.com> wrote:
> 
>> As such, the compiler should be reporting an error on such code as the above.
> 
> This is one of the 'optional' errors.

To me, there's no such thing as an "'optional' error".  An error is an error, and a warning is a warning.  Errors must always be reported, and warnings may or may not be reported depending on the compiler and how it's been configured.

To have at least one return statement in a function with a non-void return type is a requirement written into the spec.  Violating such requirements is _always_ an error.

> You can get the compiler to issue an error by using the -w switch.

-w enables warnings.  The warning that's semi-relevant is that some path through the function doesn't return, which isn't quite the same as a function having no return statements at all.

Stewart.

Don Clugston wrote:
> 
> Certainly it should be an error if a function doesn't contain any return statements at all!

void main()
{
	int function() foo = function int()
		{
			throw new Error("Function pointer not set");
		}

	/**
		logic that might not set foo;
	**/

	int i = foo();
}

On Thu, 08 Jun 2006 02:01:22 +1000, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> Derek Parnell wrote:
>> On Wed, 07 Jun 2006 22:19:47 +1000, <d-bugmail@puremagic.com> wrote:
>>
>>> As such, the compiler should be reporting an error on such code as the above.
>>  This is one of the 'optional' errors.
>
> To me, there's no such thing as an "'optional' error".  An error is an error, and a warning is a warning.  Errors must always be reported, and warnings may or may not be reported depending on the compiler and how it's been configured.
>
> To have at least one return statement in a function with a non-void return type is a requirement written into the spec.  Violating such requirements is _always_ an error.
>
>> You can get the compiler to issue an error by using the -w switch.
>
> -w enables warnings.  The warning that's semi-relevant is that some path through the function doesn't return, which isn't quite the same as a function having no return statements at all.

I'm sorry if I gave the impression that I was defending DMD on this issue. Personally I think that Walter's approach is quite daft and lacks consistency and reason. However, I'm making the generous assumption that this is one of the things that is quite low on his todo list and its just a matter of time for him to correct the situation.

-- 
Derek Parnell
Melbourne, Australia