In some situations using C/C++, I can syntactically indicate to the compiler that a returnvalue is purposely ignored:
int SomeOperation()
{
// Do the operation
return report_id;
}
int main()
{
// We execute the operation, but in this particular context we
// have no use of the report id returned.
(void)SomeOperation();
}
I find this to be a fair practice, firstly because most compilers won't generate a warning here, and secondly because it explicitly shows to future developers that the author made a concious choice to ignore the return. It makes the author's trail of thought non ambiguous.
As far as I know, the C# compiler won't complain about implicitly ignored returnvalues, but I would like to know if there's a similar convention to use in order to make a clear indication to other developers.
EDIT:
In response to some people here who questions the actual use of this convention (or that it would show bad design to have a method with a potentially unimportant return value).
A real life .NET example (which I maybe should have based the question on from the start) is the Mutex::WaitOne() overload which takes no arguments. It will only return if the mutex was safely aquired, otherwise it never returns. The boolean return value is for the other overloads where you might end up not being in possession of the mutex when it returns.
So along my reasoning, I would like to indicate in my multi-threaded code that I have made a choice to ignore the return:
Mutex mtx = new Mutex();
(void)mtx.WaitOne();
Since the returnvalue never can be anything but 'true'.