DIP 45 - approval discussion

[Rainer Schuetze]

On 14.11.2013 18:25, Benjamin Thaut wrote:
> Am 14.11.2013 08:36, schrieb Rainer Schuetze:
>>
>>
>>
>> As far as I understand, the optimization avoids generating code for
>> template instances only _created_ (not defined) by imported modules,
>> e.g. when needed for semantic analysis inside the imported module, but
>> never actually referenced by generated code by the root modules.
>>
>> [OT: The problem of the current implementation is the detection of
>> "only" in that definition, it fails too often leading to linker errors
>> and the addition of that terrible -allinst switch. I had to disable the
>> optimization for me before addition of that switch.]
>>
>> With respect to export I guess the optimization doesn't change much as
>> multiple instances of the same template instance still can be found in
>> different object files (maybe even less predictable).
>>
>> To avoid the trouble with templates, here is an idea for discussion:
>>
>> - templates definitions by themselves are never dllexport/dllimport
>>
>> - template instances are dllexport/dllimport with the proposed semantics
>> of normal functions/variables if they are explicitely declared as
>> "export" by an alias statement, e.g.
>>
>>    export alias templ!int exported_tmpl_int;
>>
>> - implicitely created template instances don't create dllexport
>> versions, and use dllimport semantics if the declaration above is found
>> in an import.
>
> I actually like this idea. Everytime I actually had to dllexport /
> dllimport templates in C++ I knew beforehand which types I need the
> template exported for.
>
> But what would should in a case like this:
>
> class WeakReferenced(T)
> {
>    export __gshared WeakReferenced!T[] m_weakTable;
> }

According to the rule above "export" on the template definition has no 
effect, only when it is instantiated with

export alias WeakReferenced!int WeakRefIntArray;

>
> Note that the export is not applied to the template directly but instead
> to a specific member inside the template.
>
> Should this be an error?

Maybe. Another rule might be that only the declarations actually 
annotated with "export" gets exported with the instantiation, so you 
could add "export" to the whole class or only some declaraations.

>
>>
>> - It's worse for the dllimport case, as data accesses to template
>> variables will sometimes use the additional indirection, sometimes not.
>
> Why exactly is that? Would that also be the case with the system
> proposed by the DIP? The dip never actually uses dllimport, so shouldn't
> it just work (tm)?
>

The problem is that the template instantiation can exist without the 
compiler seeing the alias:

-----------
module a;
class tmpl(T) { static shared int var; }

-----------
module b;
import a;
export alias tmpl!int tmpl_int;

-----------
module c;
import b;
int func() { return tmpl!int.var; } // uses dllimport access with 
indirection

-----------
module d;
import a;
int fund() { return tmpl!int.var; } // uses standard access without 
indirection

compiling c and d as single files will silently generate different code, 
because when compiling d, the export alias is never seen.

(this cannot happen with standard variables, only when declared multiple 
times, but differently, with extern(C/C++/System)).