On Thu, May 23, 2013 at 9:40 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> This seems to be a step towards what I think is the right end result. We<br>
> have two separate notions: the formal language linkage, and whether an<br>
> entity is externally visible. To that end:<br>
><br>
> (external, visible) -> ExternalLinkage<br>
> (external, not visible) -> UniqueExternalLinkage [*]<br>
> (internal, visible) -> not possible<br>
> (internal, not visible) -> InternalLinkage<br>
> (no linkage, visible) -> VisibleNoLinkage<br>
> (no linkage, not visible) -> NoLinkage<br>
><br>
> ... and the combining step takes the minimum on each axis.<br>
<br>
</div>The two cases were this would produce different result from the last patch are:<br>
<br>
InternalLinkage        VisibleNoLinkage       -> NoLinkage<br>
UniqueExternalLinkage  VisibleNoLinkage       -> NoLinkage<br>
<br>
My patch produces InternalLinkage and UniqueExternalLinkage.  Can you<br>
think of a testcase where this would be a problem?</blockquote><div><br></div><div>Yes. InternalLinkage + VisibleNoLinkage is externally visible under those merging rules, and shouldn't be.</div><div><br></div><div>Also, this doesn't match what I thought we were going to do to resolve that DR (that you take the weakest linkage of a template and its arguments for a template specialization). Why do you think these revised rules are better? What's your model?</div>
</div>