rsmith added a comment.

In, @majnemer wrote:

> Here's my thinking: the `__uuidof` expression literally declares a variable 
> called `_GUID_ddb47a6a_0f23_11d5_9109_00e0296b75d3` of type `__s_GUID` which 
> is why it behaves the way it does:

This is an implementation detail leaking, though. no? Note that that is a 
reserved name.

> I don't think it is reasonable to invent new semantics which are different 
> from the MSVC ones because we find the MSVC ones inelegant.

I mostly agree, but my point is that this is *not* the MSVC semantics, it's 
merely an implementation detail that non-conforming code happens to be able to 
observe. Suppose that `type_info` objects were similarly accessible in MSVC by 
guessing their mangled names. Would you be arguing that we should inject 
variables for those too? (And note that it is *nearly* true that `type_info` 
objects work that way: -- but the parser gets 
confused somehow when you reference them.) The only difference I can see 
between these cases is that the reserved name used for the GUID case happens to 
not contain any ?s and @s, so happens to be utterable as an identifier.

We should not attempt to be compatible with the cases where MSVC's 
implementation details happen to leak into user-visible semantics.

> What is the relative upside to a new kind of Decl? Better AST fidelity?

Yes, exactly. The same reason we don't desguar other things any more than we 
have to.

cfe-commits mailing list

Reply via email to