On Tuesday, 28 July 2020 at 14:28:09 UTC, Andrei Alexandrescu wrote:
> More progress - now __typeid comes with statically-typed overloads, so whenever T is statically known, typeid(T).whatever() will pick an efficient inlined implementation instead of a virtual call.

What's potentially interesting here is you *might* be able to add an alias StaticType = T in there and then do some pseudo-type manipulation in CTFE then get the original type back out.

Probably not there yet and might never get there but I think it would be cool if it did somehow work at some point.

On 7/28/20 10:33 AM, Adam D. Ruppe wrote:
> On Tuesday, 28 July 2020 at 14:28:09 UTC, Andrei Alexandrescu wrote:
>> More progress - now __typeid comes with statically-typed overloads, so whenever T is statically known, typeid(T).whatever() will pick an efficient inlined implementation instead of a virtual call.
> 
> What's potentially interesting here is you *might* be able to add an alias StaticType = T in there and then do some pseudo-type manipulation in CTFE then get the original type back out.

At least in some cases you can use someTypeid.toString inside a mixin.

Also, this:

static if (typeid(T1) == typeid(T2))

becomes a viable alternative to:

static if (is(T1 == T2))

Sadly it's actually longer :o).

> Probably not there yet and might never get there but I think it would be cool if it did somehow work at some point.

Yes, great idea to keep an eye out for. Thanks.

On 7/28/20 10:33 AM, Adam D. Ruppe wrote:
> On Tuesday, 28 July 2020 at 14:28:09 UTC, Andrei Alexandrescu wrote:
>> More progress - now __typeid comes with statically-typed overloads, so whenever T is statically known, typeid(T).whatever() will pick an efficient inlined implementation instead of a virtual call.
> 
> What's potentially interesting here is you *might* be able to add an alias StaticType = T in there and then do some pseudo-type manipulation in CTFE then get the original type back out.

Added: https://github.com/dlang/druntime/pull/3174/files#diff-a68e58fcf0de5aa198fcaceafe4e8cf9R441

On Saturday, 25 July 2020 at 16:34:07 UTC, Andrei Alexandrescu wrote:
> I think this has been attempted before. The TypeInfo* classes in object.d are one gnarly thing after another:
>
> https://github.com/dlang/druntime/blob/master/src/object.d
>
> Very poor usefulness to real estate ratio, ugly and inefficient implementation, etc. etc.
>
> One simple step out of this would be to replace TypeInfo_Struct with a template TypeInfo(T) if (is(T == struct)).

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"

It would also be nice for typeinfo to provide both templates and non-templated alternatives for reflection operations. For example for hasMember it could also offer:

typeid(T).hasMember("member")

While templated methods could be used to inspect types when they are known at compile time, non-templated ones may be used to inspect entities with erased type.

But this of course is not for the first step but rather one of the future ones. I hope this message provided some insight on what can be improved regarding type info, In the future.

Best regards,
Alexandru.

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")

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.

On Wednesday, 29 July 2020 at 16:46:55 UTC, Alexandru Ermicioi wrote:
> On Wednesday, 29 July 2020 at 13:27:02 UTC, Paul Backus wrote:
>>
>> 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.

The main disadvantage of using TypeInfo for this is that it doesn't work without the D runtime (i.e., in BetterC).

It's also a bit less efficient. A __traits expression is essentially a single function call inside the compiler. Using TypeInfo requires CTFE and/or template instantiation, so switching std.traits to it would make compile times (slightly) longer.

On 30/07/2020 5:36 AM, Paul Backus wrote:
> The main disadvantage of using TypeInfo for this is that it doesn't work without the D runtime (i.e., in BetterC).

If it is templated with the type which then generates the member fields of the TypeInfo, this doesn't matter.

It is no longer the responsibility of the compiler to emit the TypeInfo members, and it can be on demand even if druntime is not linked in.

On Wednesday, 29 July 2020 at 17:36:56 UTC, Paul Backus wrote:
> It's also a bit less efficient. A __traits expression is essentially a single function call inside the compiler. Using TypeInfo requires CTFE and/or template instantiation, so switching std.traits to it would make compile times (slightly) longer.

Not switching, but moving. There are some methods that would really make sense for them to be part of type info.