On 11/7/12, Andrej Mitrovic <andrej.mitrov...@gmail.com> wrote: > On 11/7/12, Jonathan M Davis <jmdavisp...@gmx.com> wrote: >> It would still break code, because then there would be a conflict which >> would have to be resolved. > > I really doubt we're going to create any new language properties > (you're the only one I can see suggesting this). And if we are, we > should use special identifiers that begin with underscores. In any > case, we can always use an alias to resolve conflicts. >
Actually, let me give you a better argument. Let's say you implement your own @(NoGC) attribute that you use in your own library. You use it like so: @(NoGC) class Foo { } And somewhere down the road 5 months from now druntime introduces it's own @NoGC attribute. Personally I would rather have a compile-time error due to clashing symbol names right then and there. Otherwise I could easily end up in a situation where I **forget** to parenthesize my custom NoGC attribute and end up using the druntime one: @(NoGC) class Foo { } @NoGC class Bar { } // oops, I meant @(NoGC) I really don't think we should have parenthesis dictate name lookup, it's way too easy to screw things up like that. Let the symbols clash so I can fix the problem with the already existing alias tools in D: alias mymod.NoGC MyNoGC; @(MyNoGC) class Foo { } @MyNoGC class Bar { } or simply: @(mymod.NoGC) class Foo { } @mymod.NoGC class Bar { } Then I can be at ease knowing I'm not accidentally using one attribute or the other because of an issue with missing parens.