Proposal for custom time string formatting in std.datetime

[Jonathan M Davis]

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