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)). Then expressions such as `typeid(MyStruct)` would be lowered to `.object.__getTypeInfo!MyStruct()`. That function uses a singleton with lazy allocation.

That means for all structs the compiler does not need to generate TypeInfo_Struct objects, and the implementation of the primitives is simpler and more efficient.

We can't do exactly this for classes because typeid(obj) is dynamic, so it requires a virtual call. But there are other ideas we can use there as well.

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:
>
> [...]

We should just complete the type info and increase the usefulness.
Removing it makes very little sense to me.

On 25.07.20 18:34, Andrei Alexandrescu wrote:
> `.object.__getTypeInfo!MyStruct()`. That function uses a singleton with lazy allocation.

What prevents putting it into the static data segment?

On 7/25/20 1:11 PM, Stefan Koch wrote:
> 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:
>>
>> [...]
> 
> We should just complete the type info and increase the usefulness.
> Removing it makes very little sense to me.

This is not proposing removal.

On 7/25/20 1:31 PM, Timon Gehr wrote:
> On 25.07.20 18:34, Andrei Alexandrescu wrote:
>> `.object.__getTypeInfo!MyStruct()`. That function uses a singleton with lazy allocation.
> 
> What prevents putting it into the static data segment?

Great idea. That can be done in the function, like here:

https://github.com/dlang/phobos/blob/master/std/experimental/allocator/package.d#L996

The overriding principle is take out trickery and magic out of the compiler and imbue the language itself with the power to express such things. Ideally the compiler would be a consistent lowering machine to a small core language with carefully defined semantics. Haskell does that:

https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/core-syn-type

It seems our community is favorable of the notion but the attitude has not quite dyed in our wool yet. Walter himself is not yet 100% there.

If we value that, typeid(Type) and typeid(expression) would lower to one of the simpler known expressions - a function call that requires no special compiler support.

On Saturday, 25 July 2020 at 18:28:46 UTC, Andrei Alexandrescu wrote:
> The overriding principle is take out trickery and magic out of the compiler and imbue the language itself with the power to express such things. Ideally the compiler would be a consistent lowering machine to a small core language with carefully defined semantics. Haskell does that:

As a developer currently writing a compiler in Haskell that outputs D code, this is something I wish D had years ago. A small well-defined core, with the restriction that any and all new features must be able to compile to the same core, means that it's much much harder to add new edge-cases and gotchas to the language.

On 7/25/20 12:34 PM, 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)). Then expressions such as `typeid(MyStruct)` would be lowered to `.object.__getTypeInfo!MyStruct()`. That function uses a singleton with lazy allocation.
> 
> That means for all structs the compiler does not need to generate TypeInfo_Struct objects, and the implementation of the primitives is simpler and more efficient.
> 
> We can't do exactly this for classes because typeid(obj) is dynamic, so it requires a virtual call. But there are other ideas we can use there as well.

Progress on this:

https://github.com/dlang/dmd/pull/11459/
https://github.com/dlang/druntime/pull/3172

Next step is to templatize the associative array primitives, which resort to horrendous tricks exactly because they lack static type information.

On Monday, 27 July 2020 at 03:31:26 UTC, Andrei Alexandrescu wrote:
> Progress on this:
>
> https://github.com/dlang/dmd/pull/11459/
> https://github.com/dlang/druntime/pull/3172
>
> Next step is to templatize the associative array primitives, which resort to horrendous tricks exactly because they lack static type information.

This might be of help in the process

https://github.com/dlang/dmd/pull/11463

It is however designed to make it easier to pin down source of unnecessary template instances triggered by `-unittest` when building

    import std;

.

On 7/26/20 11:31 PM, Andrei Alexandrescu wrote:
> On 7/25/20 12:34 PM, 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)). Then expressions such as `typeid(MyStruct)` would be lowered to `.object.__getTypeInfo!MyStruct()`. That function uses a singleton with lazy allocation.
>>
>> That means for all structs the compiler does not need to generate TypeInfo_Struct objects, and the implementation of the primitives is simpler and more efficient.
>>
>> We can't do exactly this for classes because typeid(obj) is dynamic, so it requires a virtual call. But there are other ideas we can use there as well.
> 
> Progress on this:
> 
> https://github.com/dlang/dmd/pull/11459/
> https://github.com/dlang/druntime/pull/3172
> 
> Next step is to templatize the associative array primitives, which resort to horrendous tricks exactly because they lack static type information.

Walter and I figured starting with Typeinfo_Struct is difficult, so we scaled down to the simplest: typeid(int). Take a look at:

https://github.com/dlang/druntime/pull/3174

The idea is to lower typeid(int) to __typeid!(int) and it all works nicely. We can then start generalizing from there. The code generation, putting the object in storage with static duration, all is done with standard language mechanisms.

One unexpected perk is that some functions now work during compilation. For example, with the old implementation this doesn't work:

static assert(typeid(int).toString == "int");

However, this does work:

static assert(__typeid!int.toString == "int");

which is pretty awesome. Others do, too - take a look at the unittest.

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. So TypeInfo becomes useful for static manipulation as well.

https://github.com/dlang/druntime/pull/3174/files