title: Suggestions for using attributes beyond [[noreturn]]?
body: <p>Coming from the discussions about the <em>use of vendor specific attributes</em> in another <a href="https://stackoverflow.com/q/7414829/472245">question</a> I asked myself, <strong>"what rules should we tell people for using attributes that are not listed in the standard"</strong>?</p>
  
  <p>The two attributes that are defined are <code>[[ noreturn ]]</code> and <code>[[ carries_dependencies ]]</code>. The standard leaves open how compilers should react on unknown attributes -- thus, by the standard they may stop with an error message. This is not what e.g. <em>GCC</em> does, it emits a warning and continues. This is probably a behavior to be expected by the most-common compilers. For this reason I would have like to read a "should" in the standard, but we don't have it.</p>
  
  <p>The paper N2553 brings up flexible attributes. It lists further attributes used by GCC (
  <code>unused</code>, <code>weak</code>) and MSVC (<code>dllimport</code>). for OpenMP, the widely supported parallelizing framework, scoped attributes are suggested, eg. <code>omp::for(clause, clause)</code>, <code>omp::parallel(clause,clause)</code>. So, it is very likely that we will se some vendor specific attributes very soon after they support the syntax at all, indeed. </p>
  
  <p><strong>Therefore, when we now go "out in the world" and tell people about C++11, what should the advice be about using attributes?</strong></p>
  
  <ul>
  <li>Only use <code>noreturn</code> and <code>carries_dependencies</code></li>
  <li>Use your compilers <em>old syntax</em> instead, eg. <code>__attribute__((noreturn))</code> and define a macro when you port the code (the current situation)</li>
  <li>Use those attributes your favorite compiler supports freely, knowing this code might not be portable to another standard-conforming compiler, because if the standard allows a compiler to stop with an error, you have to consider this will happen. This sounds a bit like advocating writing non-portable code.</li>
  <li>Or, my guess, expect the most-used compilers to <em>warn</em> about unknown attributes, so you can use vendor-specific attributes, keeping in mind that in rare cases you may get problems.</li>
  </ul>
  
  <p>Note the slight difference in the last two bullet-items. While both say "use those attributes you need", item3's message is "do not care about other compilers", while item4 implicitly rephrases the standard texts "implementation defined behavior" to "the compiler <em>should</em> emit a diagnostic message".</p>
  
  <p><strong>What could be the suggestion for an upcoming <em>Best Practice</em> here?</strong></p>