Problem with coupling shared object symbol visibility with protection

[Rainer Schuetze via Digitalmars-d]

On 26.01.2015 23:24, Walter Bright wrote:
>> The problem here is that you don't want to make someHelperFunc()
>> export because that would mean users could call it directly, but
>> you want it to be available for cross shared library calls. The
>> cross shared library call happens if a template is instanced from a
>> different shared library / executable than the module it was
>> originally located in.
>
> exporting a template and then having the user instantiate outside of
> the library doesn't make a whole lot of sense, because the
> instantiation won't be there in the library. The library will have to
> instantiate every use case. If the compiler knows the library
> instantiated it, it won't re-instantiate it locally.

The problem is not about into which binary the template is generated to 
(this must be the binary where it is used), but how to access private 
non-templated methods called by the template.

 From the core.time.FracSec example:

export struct FracSec
{
     ///...
     static FracSec from(string units)(long value)
         if(units == "msecs" ||
            units == "usecs" ||
            units == "hnsecs" ||
            units == "nsecs")
     {
         immutable hnsecs = cast(int)convert!(units, "hnsecs")(value);
         _enforceValid(hnsecs);
         return FracSec(hnsecs);
     }

     private static void _enforceValid(int hnsecs)
     {
         if(!_valid(hnsecs))
             throw new TimeException("FracSec must ...");
     }
     ///...
}

_enforceValid() could also be a free function. It is likely to be 
compiled into druntime.dll, but needs to be exported from the DLL to be 
callable by the instantiation of the template function in another DLL. 
The "private" forbids exporting, though.