How to get to a class initializer through introspection?

[Johannes Pfau]

Am Thu, 06 Aug 2020 12:58:22 +0000 schrieb Johan:

> Hi Johannes,
>    Can you rewrite your email without all the GDC implementation
> details? Let's keep the discussion backend-agnostic.
> 
> The questions to solve are:
> Q1 - What do we expose to the user? (an init symbol, an init function,
> typeid pointer to symbol/function for dynamic types... ?) User code
> should be able to reset an object to the init state.
> Currently user code can do that without compile-time knowledge of the
> dynamic type of an object.
> Q2 - Do we want to take care of initialization in druntime or inside the
> compilers? (currently it is done inside the compilers,
> and each backend does things its own way as long as it complies with the
> answer to Q1. Array comparison was moved from the compilers into
> druntime. It's the same kind of discussion.).
> 
> At the moment, we only provide user code dynamic access to initializer
> symbol through typeid.initializer. The idea in this thread was to add a
> way to have 'static' access that preserves type information (e.g. doing
> initialization by calling a druntime template function with type as
> template parameter).
> 
> cheers,
>    Johan

Sorry, I guess that Email Text got much longer than what I initially 
wanted to write.


In the following, I'll just call "variables with non-statically known 
type" "dynamic types".

Q1: Only an rvalue? I didn't know anything actually needs to get an 
initializer for a dynamic type. Where is this used, in the GC? If we 
really need that, we either need a pointer to an symbol or a function. I 
guess I'd agree the function is likely a better solution here. Maybe put 
it in the vtbl then, to get it out of TypeInfo.

I don't mind exposing a function to the user if it's pay-as-you-go, e.g. 
only emitted on demand. Using it for dynamic types however means we'll 
always need to emit that function. So if it's somehow possible, I'd 
rather get rid of getting the initializer for dynamic types completely.


Q2: In the compilers. My previous messages were only considering cases 
where the type is statically known. In that case, I think the compilers 
can do better than a runtime solution could. (E.g. use code based 
initializers for small types, remove redundant initialization, emit a 
single initializer function for large types as the initialization code 
may get too large (especially if duplicated), -Os vs. -O2, ...).


-- 
Johannes