On Friday, December 23, 2011 01:41:43 Walter Bright wrote: > Templates, after instantiation, are exactly like their non-templated > equivalents. Before instantiation, they are not even semantically analyzed.
That's more or less what I figured, but then again, I never would have expected having a class would be such a big deal in the first place. With the judicious use of templates, it may be possible to get the PIMPL bit to work. The problem that I see is at the moment that while a templated may not be instantiated, if it takes a particular type as a parameter (e.g. TimeZone), the type still needs to be imported. If it were just internal to the function, then a import statement could be put inside of the function, but I'm not sure how you could have a localized import like that for a parameter. Since essentially what is needed is for the module with the type to be imported when the programmer tries to instantiate the templated function but not be imported otherwise. But doing that gets rather convoluted. I _think_ that it could be done if the function used a template constraint which used an eponymous template from another module which imported the module with TimeZone in it and checked the type. But that might still pull in the class, because the module with the eponymous template imported it. I really don't understand what exactly results in the class' info being pulled into the executable. It's also a bit ugly to template a parameter which can only be one type, but that's not the end of the world if it works. So, I'm not sure that it's actually possible to get PIMPL to work here, since several functions take a TimeZone argument, and even templatizing them, I'm not sure how you avoid having to always import the module with TimeZone in it to have those functions compile properly when they're instantiated. - Jonathan M Davis