How to get to a class initializer through introspection?

Johan j at
Mon Aug 3 14:44:38 UTC 2020

On Monday, 3 August 2020 at 13:01:55 UTC, Andrei Alexandrescu 
> On 8/3/20 4:04 AM, Johan wrote:
>> On Sunday, 2 August 2020 at 23:59:23 UTC, Adam D. Ruppe wrote:
>>> On Sunday, 2 August 2020 at 22:25:19 UTC, Andrei Alexandrescu 
>>> wrote:
>>>> Any ideas on how to do that via introspection? The fields 
>>>> are accessible, but not their default values.
>>> It is ugly but possible right now to pull in the symbol via 
>>> extern(C).
>>> See line 20 in my latest blog's example:
>>> ldc complains but it is a type mismatch not a fundamental 
>>> barrier, I just didn't figure out the right thing to silence 
>>> it yet.
>>>> It seems like __traits(type, getInitializer) might be 
>>>> necessary.
>>> but yes this would be generally nicer anyway imo.
>> That for that post Adam, I've been trying the same thing 
>> lately.
>> It's needed to fix this: 
>> -Johan
> Would it be effective to iterate through the .tupleof and 
> initialize each in turn?

Possibly. IIRC, the spec obliges us to initialize the padding 
in-between address-aligned members aswell, such that a memcmp 
works to compare structs. If that is true, then we have to 
initialize the padding aswell and a memcpy would be that much 

If `__traits(type, getInitializer)` would return a symbol, then 
memcpy is easy and we're done. However, that forces us to emit 
these init symbols, except for very simple cases like all-zeros 
initialization (for which LDC does no longer emit an init 
symbol). It is very benificial for binary size to elide these 
all-zero initializer symbols. I don't know how much benefit there 
is for eliding near-zero symbols.
If `__traits(type, getInitializer)` would return a function, then 
that's a different story...

My current solution [*]:


[*] Hits an obscure mangling bug, so doesn't quite work with 
Weka's codebase yet

More information about the Digitalmars-d mailing list