@disable this for structs

[Dicebot]

On Friday, 28 February 2014 at 12:59:32 UTC, Mike Parker wrote:
>> Ideally one should use modules as namespaces :P
>
> I don't buy that. That works fine to resolve conflicts, but it 
> doesn't work for fine-grained namespace management. And when 
> using named imports, that means everything in the module then 
> belongs to that namespace, which isn't at all what I want. 
> Besides which, using either fully-qualified names or named 
> imports puts the impetus on the caller. If I design my modules 
> around namespaces with the understanding that the caller will 
> type foo.bar.myfunc all the time, there are bound to be 
> conflicts when they forget to do it.

D design is based on module as smallest composition unit. If you 
find yourself in situation where you want to have two namespaces 
in a single module, you should split it into two modules.

Putting impetus on caller (named imports) is good here and huge 
advantage over C++ way in my opinion. It gives more control over 
application naming scheme.

> On the other hand, by wrapping my namespaced stuff in structs 
> or classes, I can have multiple namespaces per module, some 
> things completely outside the namespace, and the user gets a 
> compiler error if they don't use it. To me, that's much, much 
> neater.

It simply does not fit with D type system, most importantly with 
accessiblity attributes. I'd hate to encounter all that you 
mention as "benefits" in some D library I am forced to use.