Some good ideas in this thread!

P.S. ModuleInfo doesn't list structs, only classes.

On 12/12/2022 12:57 PM, Steven Schveighoffer wrote:
> But it would be better to do that anyway, since the compiler isn't completely consistent with which classes it inserts into `ModuleInfo`.

Also, ModuleInfo can't know what to *exclude*.

On 12/12/22 11:34 PM, Walter Bright wrote:
> On 12/12/2022 12:57 PM, Steven Schveighoffer wrote:
>> But it would be better to do that anyway, since the compiler isn't completely consistent with which classes it inserts into `ModuleInfo`.
> 
> Also, ModuleInfo can't know what to *exclude*.

If Object.factory is to be a supported feature (I don't think it should be), then it has to include *all* classes. Otherwise, you have odd unrelated conditions that break the feature, and something that brittle really shouldn't be used.

-Steve

On 13/12/2022 6:32 PM, cc wrote:
> On Friday, 9 December 2022 at 22:20:28 UTC, Walter Bright wrote:
>> 4. Could we just remove it entirely?
> 
> In replacement, is something like `__traits(allModules)` not possible at that phase of compilation?

No unfortunately.

But there is something we can do, which has been on my todo list for a while now for dub:

When building a binary (executable/shared library) produce a module which contains all modules that has or is compiled into the binary.

We already kinda have this, but its only for unittesting. Just gotta make it more generic.

I intended this to go with injectSourceFiles for registering stuff like web routes.

On 13/12/22 4:17, Adam D Ruppe wrote:
> Yes, separate compilation is a thing, but you still have to `import` your dependencies.

There's dynamic loading of shared libraries, where you don't even know at compilation time what classes there might be coming.

For instance, if you implement a plugin system, and want the classes to add themselves automagically to some central registry.

In my view, the best solution for this would be to fix / extend the `this` template parameter [1] to every part of the class, in this case including static constructors:

```d
struct MyClassInfo { /* ... */ }

MyClassInfo[string] myClassRegistry;

class MyRoot {
	static this(this C) {
		import std.traits : fullyQualifiedName;

		// Gather C's metadata and store it
		myClassRegistry[fullyQualifiedName] = MyClassInfo(/*...*/);
	}
}
```

This way, you could create a hierarchy where everything inheriting from `MyRoot` would register automatically.

In an ideal world the current ClassInfo (or even an improved version of it) would be part of Object, but not of ProtoObject (what's the status of DIP1042, btw?).

[1]: https://issues.dlang.org/show_bug.cgi?id=10488

On 13/12/22 9:52, Arafel wrote:
> static this(this C)

This should obviously be `static this(this C)()`

On Friday, 9 December 2022 at 22:20:28 UTC, Walter Bright wrote:
> This adds a lot of extra size.
>
> 1. Does anybody use Object.localClasses() or Object.find() ?
>
> 2. Does anybody need them?

I don't.