One step out of the TypeInfo stalemate

Alexandru Ermicioi alexandru.ermicioi at gmail.com
Wed Jul 29 16:46:55 UTC 2020


On Wednesday, 29 July 2020 at 13:27:02 UTC, Paul Backus wrote:
> On Tuesday, 28 July 2020 at 20:37:19 UTC, Alexandru Ermicioi 
> wrote:
>> That would make typeinfo hierarchy a lot cleaner.
>> Having type known in typeinfo object would also allow 
>> implementation of reflection methods as members which in turn 
>> would make reflection based code much much cleaner from 
>> developer perspective.
>>
>> For example currently to check if member is present on type T 
>> we have to do smth like:
>>
>> __traits(hasMember, T, "member")
>>
>> When it can be more readable through typeid statement like:
>>
>> typeid(T).hasMember!"member"
>
> Well, just about anything is better than the current __traits 
> syntax. IMO an easy improvement would be to provide some syntax 
> sugar so you could write
>
>     T.__hasMember("member")
>
> and the compiler would lower it to
>
>     __traits(hasMember, T, "member")

Yep, true. Though, there is already a proper place for such 
reflection logic which are type info classes, hence I think lots 
of methods found in std.traits could just be moved under right 
type info classes.




More information about the Digitalmars-d mailing list