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