RFC: [MSVC] Late parsing of in-class defined member functions in template classes after instantiation for better compatibility.


Reid, Richard, any thoughts about this?

We've thought about it before, but we've always been able to overcome
each compatibility issue as it was encountered:

I think we need a sample ATL and WRL-based app that uses all of the
relevant headers, and instantiates all of the popular templates.
Clearly you guys are seeing issues that we never saw while building
Chromium. It's hard for us to say if a new template instantiation mode
is necessary when we're not looking at the same problems.

We're also trying to keep the scope of our compatibility limited to
whats in "system headers". If you expand the scope to be "have perfect
MSVC compatibility", then yes, the only logical solution is to to
token-based instantiation of member functions. I think if that's what
you need, then go ahead and try implementing that mode, and if it's
lightweight and non-invasive, we could take it upstream. It would be a
good replacement for -fdelayed-template-parsing.

I think now that Microsoft has started shipping clang as an option in
Visual Studio, future version of these headers are likely to get
cleaner, and eventually I'd like to turn off
-fdelayed-template-parsing by default.

Thanks for your answer.
We have many problems with samples shipped with ATL/WTL. And the main
problem is that clang founds errors not in these samples, but in ATL/WTL
header files used by these samples. I mentioned couple of examples used
in headers, which cause clang to emit errors, but also there are some
others. And it is getting harder and harder to find a way to fix these
incompatibility issues. So I think it is a wise decision to start
implementation of token-based instantiation.
We will start work on this.

Best regards,
Alexey Bataev

Reid, don't hold your breath...

(though maybe this changed since and MS compiler engineers can clarify
current standing)