<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Jan 29, 2014, at 4:16 PM, Richard Smith <<a href="mailto:metafoo@gmail.com">metafoo@gmail.com</a>> wrote:<br><div><blockquote type="cite"><div>On Wed Jan 29 2014 at 3:44:06 PM, John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">On Jan 29, 2014, at 3:32 PM, Richard Smith <<a href="mailto:metafoo@gmail.com" target="_blank">metafoo@gmail.com</a>> wrote:<br></div><div><div style="word-wrap:break-word"><blockquote type="cite">
<div>On Wed Jan 29 2014 at 3:05:34 PM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:</div><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jan 29, 2014, at 8:45 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br>
> When we see the class definition, we already have to cache the tokens in member functions until we hit the close brace. It doesn't seem too hard or expensive to look ahead and see if we have a typedef name for linkage purposes if the class is anonymous and is preceded or followed by typedef.<br>
<br>
I don’t think we can actually tentatively parse declarators. Remember that we might have something like<br>
<br>
typedef struct { … } (*FnType)(), (*ArrayType)[sizeof(decltype(<u></u>declval<FnType>()()))], StructType;<br>
<br>
because C++ is dumb.<br>
<br>
But obviously we could recognize some simple cases and limit the damage of my proposed diagnostic.<br></blockquote><div><br></div><div>Your example doesn't seem to show a problem (since we're just looking to see if there's any declarator with nothing more interesting than parens around the declarator-id). I can imagine trouble with something like this, though:</div>
<div><br></div><div>typedef struct { ... } *A, X<Y<A>::Z < Q>::*foo, S;</div><div><br></div><div>(because we don't know if the < after 'Z' begins a template-argument-list or not). Yes, this may be infeasible.</div>
</blockquote><div><br></div></div></div><div><div style="word-wrap:break-word">My example was just to show that we’d need tentative parsing to handle declaring new names, but yes, yours much more clearly shows that we’d need to perform arbitrary instantiation.</div>
<div></div></div><div><br><blockquote type="cite">
<blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> Can this go wrong in any non-delay-parsed context?<br>
<br>
‘this’ is legal in some non-delay-parsed contexts, namely trailing result types.<br>
<br>
Do you have any objection to adopting my proposed diagnostic as a semi-temporary fix? All the code it would affect currently triggers an assertion, and frankly it feels like a “real” fix here would require a pretty disproportionate amount of effort for the expected benefit.</blockquote>
<div><br></div><div>I'm fine with it right up until people start filing bugs saying we broke them ;-)</div></blockquote><div><br></div></div><div><div>At which point you’ll stab me in the back and declare yourself for The People, got it. :)</div>
</div><div><div><br><blockquote type="cite"><div>Honestly, I think your approach of a diagnostic in this case is not only reasonable, it's a reasonable thing to propose as a DR, assuming it doesn't break the world.</div>
</blockquote></div><br></div><div><div>I’m not sure what a reasonable formal rule here would be, but if you can think of one, that sounds great. Using ‘this' in a non-delayed context in an anonymous type that later receives a typedef name for linkage purposes? That would require us to parse the declarators before doing the delayed parsing, which is awkward because those names (1) do have to be in scope during subsequent declarators but (2) can’t be in scope (including qualified scope) during the delayed parsing, but that’s certainly more feasible than completely reworking stuff to not do any linkage queries.</div>
</div></blockquote><div><br></div><div>The examples I've seen so far all rely on us needing to compute the linkage of the type when it's used as a template argument (which, incidentally, the standard does *not* currently require, but see core issue 1602). Are there other cases that we care about?</div></blockquote><br></div><div>As far as I know, except for the no-longer-required template argument linkage check, it’s not actually semantically required for anything except code generation, but we do have umpteen diagnostics that check stuff like isExternallyVisible().</div><div><br></div><div>John.</div></body></html>