On 18 December 2012 20:11, Johannes Pfau <nos...@example.com> wrote: > Am Tue, 18 Dec 2012 20:06:16 +0100 > schrieb "jerro" <a...@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{} >
Someone recently mentioned @gccAttribute("foo", "bar"); as a prototype. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';