On 2/21/13 8:34 PM, Jonathan M Davis wrote:
> On Friday, February 22, 2013 00:06:26 bearophile wrote:
>> Jonathan M Davis:
>>> D doesn't
>>> bother to check, so you get the natural consequence of mixing
>>> them. I'm quite
>>> sure that the fact that it works that way is an accident. It
>>> was never
>>> intentially made to be allowed or disallowed. It's just
>>> allowed, because
>>> there's nothing intrinsic about either of the attributes which
>>> makes it
>>> illegal, and no effort was made to do prevent it (it probably
>>> didn't even occur
>>> to Walter that anyone would do it). I'd expect it to continue
>>> to work though,
>>> since it doesn't really harm anything,
>>
>> According the way my brain works, sometimes I find the D compiler
>> unnervingly sloppy.
>
> True enough, but in this case, I don't think that it's a problem.

If the compiler gave you an error if you put "static" on a top-level class definition, this whole thread wouldn't exist.

Don't you see that as a problem? People loosing their time answering this questions over and over again instead of the compiler giving you the answer.

On Friday, February 22, 2013 00:59:45 Ary Borenszweig wrote:
> On 2/21/13 8:34 PM, Jonathan M Davis wrote:
> > On Friday, February 22, 2013 00:06:26 bearophile wrote:
> >> Jonathan M Davis:
> >>> D doesn't
> >>> bother to check, so you get the natural consequence of mixing
> >>> them. I'm quite
> >>> sure that the fact that it works that way is an accident. It
> >>> was never
> >>> intentially made to be allowed or disallowed. It's just
> >>> allowed, because
> >>> there's nothing intrinsic about either of the attributes which
> >>> makes it
> >>> illegal, and no effort was made to do prevent it (it probably
> >>> didn't even occur
> >>> to Walter that anyone would do it). I'd expect it to continue
> >>> to work though,
> >>> since it doesn't really harm anything,
> >> 
> >> According the way my brain works, sometimes I find the D compiler unnervingly sloppy.
> > 
> > True enough, but in this case, I don't think that it's a problem.
> 
> If the compiler gave you an error if you put "static" on a top-level class definition, this whole thread wouldn't exist.
> 
> Don't you see that as a problem? People loosing their time answering this questions over and over again instead of the compiler giving you the answer.

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.

In general, I do agree that the fact that the compiler doesn't complain about inapplicable attributes is a problem. There are some good arguments with regards to generic programming which make it so that having the compiler complain could be problematic, but I'm not completely convinced that we can't have the compiler complain at least _some_ of the time. And as for static in particular, I doubt that it ever makes sense for it not to be complained about if it's used where it doesn't apply. But Walter doesn't see it as a problem. I suspect that a detailed analysis (possibly even a DIP) would be required to show where it would make sense to make inapplicable attributes illegal and where it wouldn't. Certainly, just complaining about it won't convince Walter.

- Jonathan M Davis

On 2/22/13, Ary Borenszweig <ary@esperanto.org.ar> wrote:
> Don't you see that as a problem? People loosing their time answering this questions over and over again instead of the compiler giving you the answer.

They're losing their time if they expect D to act as another language.

Anyway an annoying compiler complaining about static is worse than having the occasional question being asked in the newsgroups.

It's natural and would be good if something will be stated in documentation about static at top-level.

"static" is well known feature. Yes it can act differently in diff languages.

> They're losing their time if they expect D to act as another language.

With this point of view to user, only D will lose.

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:

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

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

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

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

In D a module can be statically imported and then I can use full names.

But question: is it possible to force a static import?

On Friday, February 22, 2013 22:12:44 Michael wrote:
> In D a module can be statically imported and then I can use full names.
> 
> But question: is it possible to force a static import?

No.

- Jonathan M Davis