@disable this for structs

[Mike Parker]

On 2/28/2014 10:21 PM, Dicebot wrote:
>
> 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.

Consider this.

enum Foo {...}

interface Bar {}

struct BarManager {
    public static {
       void initialize();
       void terminate();
       ... more stuff
    }
}

This is my use-case. I don't want my users to have to refer to Foo or 
Bar with any sort of prefix except to avoid name-clashes. However, I 
want to logically group the functions to manage Bars under a single 
grouping. I don't need or want a Singleton for it. I could use free 
functions, but I use the initialize/terminate idiom a lot. As a user of 
my own library, it would be horribly annoying to have to fully qualify 
each call. Plus, now and again I have multiple "namespace structs" in a 
single module. If I see them as all being closely related, why should I 
split them off into different 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.

One of the most annoying things for me in C++ is to see something like 
some::ridiculously::long::namespace, that I then have to use on each 
type declared in that namespace. That makes me add using statements to 
the top of each module, which defeats the purpose in the first place. I 
would find it equally annoying in D if every module I imported required 
me to use a fully-qualified module name. Luckily, that isn't the case. 
We only need to do it do avoid conflicts.

My purpose for using namespaces in this way is twofold: to indicate that 
those particular functions serve a collective purpose, and to make give 
more meaning to the user code. I don't need to worry about naming 
conflicts, thanks to the module system, but I don't see the module as 
the smallest unit of organization.