   Never return void?
  Hi, I had a brief conversation with a colleague who stated, 'a method should never return void'. I rejected the idea out of hand, and we didn't have time to discuss it. So I was wondering if anyone here has heard of this idea or knows why this would be desirable. I have to confess I have no idea why this would be a good idea. Just to be clear I don't mean explicitly trying to return a void or void* or something, but having a void return type on a method signature.
  well if you meanvoid SetX(int x); like thati dont know why that would be bad unless you want to return a value to check if the function exectued proper but if you mentvoid SetSelected(int mousex, int mousey){for(int i = 0... iteration lol ){    if(the condition is met)    {    m_selected = i;   return;    }}}then idk y that would be bad.. or if somthing happened that you dident want to happen.. sorry thats not much info but i thought i would give it a shot   ;  Some functions simply have no output, period.That said, for some Set methods, it's sometimes pertinent to return a reference to the object so you can use cascading calls like this:Rect.SetLeft( 0 ).SetRight( 320 );;  It's the same nosense as saying that "a method should only have one return point" and that assholes people who think that know everything will rub on your face as undenyable truth and look at you like meaning "you're ignorant".Shame on them.;  Sometimes this attitude goes hand-in-hand with an avoidance toward structured exception handling -- In the absence of exceptions, return values are really the only way to communicate that something has gone wrong in the function, and so it is reasonable to then assume that any function that can fail needs some kind of return value. Of course, using this kind of error-code return value may then necessitate the use of out-params if the return value and error code cannot be reconciled into the same return type.Another, poorer argument is that no return value tends to imply that state is modified in some other way, which can certainly be abused. I say this is a poorer argument as the real problem is the abuse of state, and having a return value doesn't actually fix the problem unless you use it as a means to fix the other problem.Your colleague may also come from a more functionally-minded (in the way of, say, Haskell or another functional programming language, not C-style 'functions', which are, more accurately, procedures.) background, and they perhaps tend to think in this way.In general, its probably true that a tendency toward actual return values is a good thing, but I wouldn't go out of my way to avoid 'void' if it were the natural way to express the behavior. I prefer SEH to handle and communicate exceptional cases myself, but there are places which discourage or outlaw exceptions in their C++ code -- Google, for example, forbids exception handling in their C++ coding standard, its often forbidden in the embedded world (what little part of it that has embraced even some C++), and EA has their "EASTL" which provides STL-like functionality aimed at gaming applications and which also avoids exception handling -- as a side note, you can actually compile most STL implementations without exception handling.   ;Quote:Original post by BearhuggerSome functions simply have no output, period.That said, for some Set methods, it's sometimes pertinent to return a reference to the object so you can use cascading calls like this:*** Source Snippet Removed ***It may be semantics, but actually all functions, in the pure sense, return at least one value, take at least one parameter, has no side-effects, accesses no global data and calls only other pure function. If any one of these requirements is not satisfied, then you're really talking about a procedure, or subroutine.Making the distinction is actually very important these days, as pure functions can be made parallel trivially, which is a hot topic for optimization in today's multi-core, distributed and parallel-processing world (SIMD, CUDA, OpenCL, etc).EDIT: Another feature of "pure" functions is that they are inherently testable due to the fact that all paths into and out of the function are known. If you know the function works for all input values and produces only expected outputs, then that function is secure, and other secure functions may call it also and retain their security. Actually, I kind of wish C and C++ would adopt some sort of "pure" keyword so the compiler could prevent you from doing unpure things in functions you intend to be pure.[Edited by - Ravyne on August 31, 2010 9:03:10 PM];  It's a strictly C thing.As per:Quote:The type-specifier can specify any fundamental, structure, or union type. If you do not include type-specifier, the return type int is assumed. While likely a perfectly valid concept, following the principle of least surprise, use a type.   ;  Antheus -- But the OP is saying that the return type on the method signature is given explicitly as 'void'. Your source lists 'void' as a valid type specifier, so I'm confused on what point you are trying to make. Explain?   ;  I've heard this argument made a little. It's done by people who favor a bit more idealistic view of things. They tend to be functional programmers who're for some reason or another stuck in a not functional language. The basic concept is that functions should do things. A function that returns void doesn't do anything (and doesn't line up with the mathematical concept of a function), it just sucks in parameters and does some weird side effect that isn't elegant, or testable, or nice (in their view). And if you're coming from a world where side-effects are offensive to the extreme... it kinda sorta makes sense.Though that is (imo) a bit impractical.   ;Quote:Original post by RavyneAntheus -- But the OP is saying that the return type on the method signature is given explicitly as 'void'. Your source lists 'void' as a valid type specifier, so I'm confused on what point you are trying to make. Explain?If you don't specify a type, int is automatically selected by compiler.foo(int x) {  printf("%d", x);}// is same asint foo(int x) {  printf("%d", x);}This is the best I can interpret the original "having a void return type on a method signature."   