From: philip.shaw@internode.on.net   
      
   One problem with your idea is that it can't be applied to functions   
   which return a pointer to an object without changing the semantics.   
   That's because the compiler isn't intelligent enough to know who owns   
   the object: if the caller doesn't own the object, it is easy to deal   
   with because something else will eventually delete it. OTOH, if the   
   caller does own it, dropping the pointer would, at present, create a   
   memory leak. (New code would still work, in old compilers, but I don't   
   think it is acceptable to introduce problems with a language change). We   
   could get around that with annotations, and only create no-return   
   versions of functions where that won't create a problem, but it would be   
   rather tricky.   
      
   If the collection were not accessible outside its own translation unit,   
   I'm fairly sure the compiler would do dead code elimination as you   
   suggest. In a statically linked program I think LLVM does more dead code   
   elimination at link-time (and I would presume that GCC has, or soon will   
   have, equivalent functionality).   
      
   The tricky part comes to dynamically linked libraries, because we need a   
   backwards-compatible way to specify whether the caller wants a return   
   value. I can think of two ways to do it:   
      
   * *name mangling*: This is probably the simplest way: create a void   
   version of each function, with a different name, and modify LD so that   
   when the void version is called on an old library, the normal version is   
   called and the return value dropped.  The downside of this is a slowdown   
   when working with old libraries and that it would be difficult to make   
   work with functions which return pointers. However, if we didn't care   
   about being able to link with old libraries and using redundant-return   
   elimination, or if it were acceptable to have to maintain a list of   
   new-type libraries, this would be much easier (no modifications to LD   
   would be required).   
      
   * *hidden parameter*: If a "spare" flag location can be found (which   
   would be architecture-dependent) it would be possible to test that   
   within the function and, if it is set, return a dummy value (whatever   
   junk data is in the return slot).   
      
   Personally, I think the first option is preferable because it is cleaner   
   and more elegant, but compatibility problems might be unacceptable in   
   the commercial world.   
      
   I'm not sure whether it is a good idea to expose the void-return flag to   
   programmers. Compatibility isn't an issue, since if programmers want to   
   use it with old compilers they can define it as false, but it might   
   encourage bad programming practices. However, since C and C++ generally   
   follow the principle of allowing the programmer to do anything and   
   trusting him to be sensible, the possibility of massive manual   
   optimisation would make it worthwhile.   
      
   While it wouldn't be overly difficult to add this feature to C++, I'm   
   not sure whether the benefits would justify the transition costs, since   
   the workaround of duplicating functions is inelegant but effective.   
      
   Also, most of the time computing the return value is cheap or a   
   void-variant is pointless, so there needs to be a very cheap way to   
   handle the odd times when someone wants to call the void form of those   
   functions. Whether that could be done in a way which doesn't eat the   
   efficiency gains would be a rather interesting research project, which I   
   unfortunately don't have time to do right now. Annotating the   
   declarations would probably be the solution, especially as that would   
   allow the creation of warnings where return values are ignored when they   
   probably shouldn't be (for example, when using parts of cstdlib).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)