digitalmars.D.bugs - [Bug 180] New: DMD accepts a function with a non-void return type but no return statements
- d-bugmail puremagic.com (32/32) Jun 07 2006 http://d.puremagic.com/bugzilla/show_bug.cgi?id=180
- Derek Parnell (6/8) Jun 07 2006 This is one of the 'optional' errors. You can get the compiler to issue ...
- Don Clugston (21/29) Jun 07 2006 I really don't understand why it's optional.
- BCS (12/15) Jun 07 2006 void main()
- Stewart Gordon (12/19) Jun 07 2006 To me, there's no such thing as an "'optional' error". An error is an
- Derek Parnell (10/27) Jun 07 2006 I'm sorry if I gave the impression that I was defending DMD on this issu...
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.
--
Jun 07 2006
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
Jun 07 2006
Derek Parnell wrote:On Wed, 07 Jun 2006 22:19:47 +1000, <d-bugmail puremagic.com> wrote: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!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.
Jun 07 2006
BCS <BCS pathlink.com> 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(); }
Jun 07 2006
Derek Parnell wrote:On Wed, 07 Jun 2006 22:19:47 +1000, <d-bugmail puremagic.com> wrote: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.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.-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.
Jun 07 2006
On Thu, 08 Jun 2006 02:01:22 +1000, Stewart Gordon <smjg_1998 yahoo.com> wrote:Derek Parnell wrote: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, AustraliaOn Wed, 07 Jun 2006 22:19:47 +1000, <d-bugmail puremagic.com> wrote: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.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.-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.
Jun 07 2006