core.reflect vs. __traits

[Alexandru Ermicioi]

On Saturday, 3 July 2021 at 16:08:59 UTC, Stefan Koch wrote:
> On Saturday, 3 July 2021 at 15:46:07 UTC, Alexandru Ermicioi 
> wrote:
>> On Saturday, 3 July 2021 at 11:59:03 UTC, Stefan Koch wrote:
>>> Good Day D Community,
>>>   ...
>>> Please let me know what you think.
>>
>> Hi, any thoughts, on integrating core.reflect with typeinfo 
>> classes?
>> Seems like, right place for reflection information to be 
>> stored.
>>
>> Also any plans on providing a good interface for invoking 
>> functions and class members?
>> Would be nice to have two sets of functionality, one for 
>> compile time, and one at run time.
>>
>> Best regards,
>> Alexandru.
>
> typeinfo is a failed experiment in my opinion which has never 
> been useful and this is why I am working on `core.reflect`.

Why do you think it is a failed experiment?

 From the looks of it reflection info you're designing has perfect 
place: TypeInfo. Of course, current type info architecture might 
not be satisfactory, but with some improvements it can 
accommodate core.reflect functionality.

It's true, type info seems half finished thing, but for features 
it already provides it is quite useful, which mainly is type 
identification at runtime. For example my pet project aedi which 
is a dependency injection container, boxes all managed components 
and erases their type when stored in a container. If an user 
wants a component out of container, it will check whether the 
desired component matches the type client expects by doing a 
typeinfo equality check, and if not throw an exception.

> The functionality for runtime and for compile time (as far as 
> working with reflection classes in concerned) should be the 
> same.

So say given a name of a method as string and an instance of a 
class that has that method at runtime (not ctfe) will I be able 
to call that said method on the instance?