Thanks for the info. Do you happen to know why C++11 has this rule?<br><br>I got into this as I noted the same was implemented in gcc 4.8 [1] while working on attributes. There are several options:<br>- Forbid C++11 attributes on explicit template instantiations and treat such program as ill formed.<br>
- Issue a warning and ignore the attributes. This seems what gcc is doing.<br>- Issue a warning but not ignore the attributes. This allows existing visibility attributes migrate to new syntax with same semantics. <br><br>
Which is the right direction to go here?<br><br>[1] <a href="http://gcc.gnu.org/viewcvs/trunk/gcc/cp/decl.c?r1=192199&r2=192198&pathrev=192199">http://gcc.gnu.org/viewcvs/trunk/gcc/cp/decl.c?r1=192199&r2=192198&pathrev=192199</a><br>
<br>Michael<br><br><div class="gmail_quote">On Tue, Dec 11, 2012 at 8:01 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Dec 7, 2012, at 3:08 PM, Michael Han <<a href="mailto:fragmentshaders@gmail.com">fragmentshaders@gmail.com</a>> wrote:<br>
> This small patch forbids C++11 attributes on explicit template instantiations, as required by C++11 [dcl.attr.grammar] p4.<br>
<br>
</div>Hmm.  It's easy to imagine attributes that are useful on explicit template instantiations.  We already support visibility attributes here (to override the visibility of the instantiated symbols), and we've discussed having an attribute which would guarantee a unique explicit instantiation (allowing the symbols to be emitted with strong linkage).  So this is a rather unfortunate language rule, and it undermines any argument that people ought to prefer the new syntax for existing attributes.<br>

<span class="HOEnZb"><font color="#888888"><br>
John.<br>
</font></span></blockquote></div><br>