The future of UDAs.

[Max Samukha]

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.