If you accidently leave out a return statement, a runtime error occurs when
that path is executed. It used to be that the error would be a system-level
one (a halt instruction, I think?) which gave no useful information
whatsoever about the original problem.
The recent compiler versions have apparently changed this (or at least
something better happens without -O) such that an assert error is emitted ~
this at least shows the filename and line number. Hoorah! Hoorah! However,
it would be much more helpful if the assert message said something more than
"Error: AssertError Failure token(29)"
Is it just not technically possible to emit a message of the form "Missing
return statement in token.d (29)" ?

If you accidently leave out a return statement, a runtime error occurs when
that path is executed. It used to be that the error would be a system-level
one (a halt instruction, I think?) which gave no useful information
whatsoever about the original problem.
The recent compiler versions have apparently changed this (or at least
something better happens without -O) such that an assert error is emitted ~
this at least shows the filename and line number. Hoorah! Hoorah! However,
it would be much more helpful if the assert message said something more than
"Error: AssertError Failure token(29)"
Is it just not technically possible to emit a message of the form "Missing
return statement in token.d (29)" ?

I think it is possible. Instead of inserting
#assert(false);
the compile would have to insert
#throw new ReturnException("Function " ~ func.magic.name ~ " exited
without returning anything");
where func.magic.name would be something like the
#this.classinfo.name
except it should return the function name.
I don't know if such a thing exists or not.

Is it just not technically possible to emit a message of the form "Missing
return statement in token.d (29)" ?

It's technically possible, but it may go against what Walter intends for
assertions as he's been somewhat resistant to the suggestion of
assertion messages in the past. But I'd love for this to change. Since
shipping code does sometimes leave assertions in place, I'd prefer if
there were some way to display meaningful error messages on termination.
It also offers a way to track down the offending line without digging
through the version control archives. The change would be relatively
simple. Add support for an optional char[] argument in asserts and pass
this through to the callback function. Then the code generated for end
of line messages could be:
assert( 0, "Missing return statement." );
instead of:
assert( 0 );
Sean

This seems like something the compiler should check. I seem to recall my C++
compiler warning me "not all paths return a value", or something similar.
Sean Kelly wrote:

Kris wrote:

Is it just not technically possible to emit a message of the form
"Missing return statement in token.d (29)" ?

It's technically possible, but it may go against what Walter intends for
assertions as he's been somewhat resistant to the suggestion of
assertion messages in the past. But I'd love for this to change. Since
shipping code does sometimes leave assertions in place, I'd prefer if
there were some way to display meaningful error messages on termination.
It also offers a way to track down the offending line without digging
through the version control archives. The change would be relatively
simple. Add support for an optional char[] argument in asserts and pass
this through to the callback function. Then the code generated for end
of line messages could be:
assert( 0, "Missing return statement." );
instead of:
assert( 0 );
Sean