title: Can Doxygen include a function in a member group but not document it?
body: <p>Using Doxygen 1.7.4</p>
  
  <p>Sometimes I'll have a block of public member functions that belong <strong>in a member group</strong> and that I feel are self documenting (e.g. getters/setters), so I don't want to write Doxygen syntax for each one. However, I may need to add something like a <code>\note</code> to one or two of them. Also, I <em>do</em> still want the function declarations to show up in the class's member list in the final documentation. Therefore, using <code>\cond</code>, <code>\endcond</code> won't work. I've noticed that if all parent elements are documented and Doxygen encounters an undocumented function in a member group, it will repeat the first documentation it encountered in that group, even if that documentation was for a function of a different name, as such:</p>
  
  <pre><code>/** @name Group1
   *  @{
  */
  void setA( int i );
  int  getA( void );
  
  /// @note This note unexpectedly repeated for all functions in this group
  void setB( int i );
  
  int  getB( void );
  void setC( int i );
  int  getC( void );
  //@}
  </code></pre>
  
  <p>To anybody reading the code and documentation, it should be obvious that the note should only apply to <code>setB()</code>.</p>
  
  <p>This particular problem goes away if I remove the surrounding member group. However, that defeats the documentation purpose that these functions somehow belong together, and Doxygen then complains (warns) that the functions aren't documented. I've tried adding empty special comment blocks and empty <code>\brief</code> and <code>\note</code> commands, all to no avail.</p>
  
  <p>I also encounter this phenomenon when documenting overloaded functions in a member group. If my overloaded function uses a different number of parameters and different parameter names, I'll document that function separately. However, sometimes two functions will only differ by the parameter type. In this case, my workaround has been to use the <code>\overload</code> command. However, I'd prefer to not have to do this, and this workaround does not apply (semantically) for functions of a different name.</p>
  
  <p>So, is there any workaround to this repetition problem?</p>