static class

[Jonathan M Davis]

On Friday, February 22, 2013 20:39:01 Michael wrote:
> On Friday, 22 February 2013 at 04:06:09 UTC, Jonathan M Davis
> 
> wrote:
> >I'm not talking about static. I'm talking about the fact that
> >putting both final and abstract on a class isn't a problem.
> >
> > - Jonathan M Davis
> 
> Initial question for me was how to get something like:

Yes, but Bearophile was commenting on the fact that the compiler
doesn't complain when you mark a class as both abstract and final,
and that's what I was responding to in that post.

> >They only contain static members.
> >They cannot be instantiated.
> >They are sealed.
> >They cannot contain Instance Constructors

Marking a class as both abstract and final is the closest that you're
going to get.

> But topic shows that not only for me and top-level static have
> unclear state.

Top-level static means nothing on anything. It's a no-op. The fact
that inapplicable attributes are frequently ignored does cause some
confusion, but there's nothing special about static in that regard.

> This topic (and others) will pop-upped many times by newcomers.

Actually, it's quite rare. C# and Java don't have free functions, so you're 
forced to create classes to hold them. D has no such restrictions, making 
classes like that almost useless. The only value that they really give you is 
to be able to force a function to be called with its outer "namespace." If you 
namespace stuff with modules (as is expected in D), then you can call a 
function without its full import path and therefore without any namespacing
(e.g. find instead of std.algorithm.find), whereas if it's on a class, then
you can't (e.g. you use Clock.currTime for std.datetime.Clock.currTime and
not just currTime), because the class isn't part of the import path. There
are a couple of places in Phobos where a class is used like this, but it's
generally complained about, and the practice is almost universally shunned.

- Jonathan M Davis