On 11/27/2012 11:36 PM, Gor Gyolchanyan wrote:
> It has to be in a single function. Suppose you have a variety of modules
> each of which has a variety of types. And you need to compose a
> compile-time string which involves all those types and you need to mix
> that string in at some point. You can't do that.

I don't see any reason why that wouldn't work now. CTFE is not limited to one function.

    enum i = foo() + foo();
    pragma(msg, i);

prints 20.

On 11/27/2012 10:37 PM, Iain Buclaw wrote:
> As far as I can tell, it's all just metadata known at compile-time
> only.  Nothing is written in the resultant binaries or object files
> produced.

That's right. However, you can use CTFE to read those UDAs and generate results that are embedded into the object files.

On 11/28/2012 3:59 AM, David Nadlinger wrote:
> On Tuesday, 27 November 2012 at 15:49:45 UTC, Gor Gyolchanyan wrote:
>> Can you implement this use case?
>> Have classes mix in something,, which will register them in a single
>> place,
>> which can later suppl the registered classes as a type tuple.
>
> This is fundamentally impossible in the D module system if the "single
> place" S does not import the modules where the types are defined. Even
> if you could append strings to a "compile-time global" in S, this still
> wouldn't help you in any way because if you tried to mix in the string
> in S, you'd get nothing but a slew of undefined symbol errors.
>
> Maybe you can describe your use case a bit? I'm optimistic that there is
> a solution which is not radically incompatible with the design of D.
>
> David

In general, D even tries to avoid the concept of a "global". Modules are supposed to be unknown (and unknowable) unless they are imported (directly or transitively).

However, modules can self-register their contents to some imported "registry" via code in their static constructor.

I do not think this is a burden, because UDAs cannot be externally applied to an import. A module must be editted and the UDAs specifically added to them, so adding some boilerplate to the static constructor should not be an issue.

On Tuesday, 27 November 2012 at 16:19:59 UTC, Manu wrote:
> On 27 November 2012 17:49, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com>wrote:
>
>> Can you implement this use case?
>> Have classes mix in something,, which will register them in a single
>> place, which can later suppl the registered classes as a type tuple.
>>
>
> I don't do it as a type tuple, why do you need that?
> I do it as a runtime registry.
>
> I have 'mixin RegisterModule;' at the top of every module.

And at this point we are back to the famous problem with static constructors in circularly imported modules:

module a;
import b;
mixin RegisterModule;


module b;
import a;
mixin RegisterModule;

On Tuesday, 27 November 2012 at 21:48:52 UTC, Walter Bright wrote:
> On 11/28/2012 3:59 AM, David Nadlinger wrote:
>> On Tuesday, 27 November 2012 at 15:49:45 UTC, Gor Gyolchanyan wrote:
>>> Can you implement this use case?
>>> Have classes mix in something,, which will register them in a single
>>> place,
>>> which can later suppl the registered classes as a type tuple.
>>
>> This is fundamentally impossible in the D module system if the "single
>> place" S does not import the modules where the types are defined. Even
>> if you could append strings to a "compile-time global" in S, this still
>> wouldn't help you in any way because if you tried to mix in the string
>> in S, you'd get nothing but a slew of undefined symbol errors.
>>
>> Maybe you can describe your use case a bit? I'm optimistic that there is
>> a solution which is not radically incompatible with the design of D.
>>
>> David
>
> In general, D even tries to avoid the concept of a "global". Modules are supposed to be unknown (and unknowable) unless they are imported (directly or transitively).
>
> However, modules can self-register their contents to some imported "registry" via code in their static constructor.
>
> I do not think this is a burden, because UDAs cannot be externally applied to an import. A module must be editted and the UDAs specifically added to them, so adding some boilerplate to the static constructor should not be an issue.

And for several years we've been trying to tell you that that does not work in the presence of circular imports.

On 28 November 2012 17:47, Max Samukha <maxsamukha@gmail.com> wrote:

> On Tuesday, 27 November 2012 at 16:19:59 UTC, Manu wrote:
>
>> On 27 November 2012 17:49, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com>* *wrote:
>>
>>  Can you implement this use case?
>>> Have classes mix in something,, which will register them in a single place, which can later suppl the registered classes as a type tuple.
>>>
>>>
>> I don't do it as a type tuple, why do you need that?
>> I do it as a runtime registry.
>>
>> I have 'mixin RegisterModule;' at the top of every module.
>>
>
> And at this point we are back to the famous problem with static constructors in circularly imported modules:
>
> module a;
> import b;
> mixin RegisterModule;
>
>
> module b;
> import a;
> mixin RegisterModule;
>

Certainly a potential problem, but I've set up my code such that these
static constructors themselves have no external dependencies, and
initialisation order is unimportant, since registered stuff just ends up in
a globally accessible hash table anyway.
Not a problem for me, but I have encountered this problem in other
situations, and also prototype configurations ;)

On Wednesday, 28 November 2012 at 15:54:52 UTC, Manu wrote:
>>
>> module a;
>> import b;
>> mixin RegisterModule;
>>
>>
>> module b;
>> import a;
>> mixin RegisterModule;
>>
>
> Certainly a potential problem, but I've set up my code such that these
> static constructors themselves have no external dependencies, and
> initialisation order is unimportant, since registered stuff just ends up in
> a globally accessible hash table anyway.
> Not a problem for me, but I have encountered this problem in other
> situations, and also prototype configurations ;)

That is a problem for anyone who builds a library for general use. Static constructors in mixins are inapt unless you want to impose a certain project structure (no circular imports) on your users.

On 2012-11-28 16:54, Manu wrote:

> Certainly a potential problem, but I've set up my code such that these
> static constructors themselves have no external dependencies, and
> initialisation order is unimportant, since registered stuff just ends up
> in a globally accessible hash table anyway.

It doesn't matter if the static constructors don't have any external dependencies. You can have an empty static constructor in two modules which import each other. That will result in an exception being thrown at runtime.

-- 
/Jacob Carlborg

On 28 November 2012 21:08, Jacob Carlborg <doob@me.com> wrote:

> On 2012-11-28 16:54, Manu wrote:
>
>  Certainly a potential problem, but I've set up my code such that these
>> static constructors themselves have no external dependencies, and initialisation order is unimportant, since registered stuff just ends up in a globally accessible hash table anyway.
>>
>
> It doesn't matter if the static constructors don't have any external dependencies. You can have an empty static constructor in two modules which import each other. That will result in an exception being thrown at runtime.


Well fortunately that hasn't happened yet... That does worry me though. I can't imagine a work-around if that comes up.

On Wednesday, 28 November 2012 at 19:57:34 UTC, Manu wrote:

>
> Well fortunately that hasn't happened yet... That does worry me though. I
> can't imagine a work-around if that comes up.

Just a random thought: what if the compiler didn't check cycles for modules that define only static ctors attributed with @system/@trusted?