Should compilers take advantage (abuse) of the new UDA syntax that has been accepted?

[Simen Kjaeraas]

On 2012-11-18 21:12, Johannes Pfau <nospam at example.com> wrote:

> Am Tue, 18 Dec 2012 20:06:16 +0100
> schrieb "jerro" <a at a.com>:
>
>> You could also define them in compiler
>> specific modules as has already been discussed in this thread,
>> but then code that used them without full names (including the
>> module name) would break if an attribute with the same name was
>> added to the language.
>
> We could do this: Language attributes (@property, @safe, ...) are
> defined in "lang.attributes" (or choose some other name). Then add a
> public import of lang.attributes to object.di.
>
> GDC attributes are defined in gdc.attributes (or any other name). We
> could add an public import to object.di for gdc. Or we don't, that's a
> different discussion.
>
> The result is that you can always resolve conflicting attributes:
> If gdc introduces @noreturn in gdc.attributes you can now do this:
> ------------------------
> //(Optional if gdc.attributes is imported in
> //object.di)
> import gdc.attributes;
>
> @noreturn void foo{}
> ------------------------
>
> If a @noreturn attribute is now added to lang.attributes, the compiler
> will refuse to compile the above code as it's ambiguous. But you can
> now do this:
>
> @lang.attributes.noreturn void foo{}
> or
> @gdc.attributes.noreturn void foo{}
>
> or
> import gdc = gdc.attributes;
> @gdc.noreturn void foo{}

This certainly sounds like the sanest solution.

-- 
Simen