Bug 5868 – static attribute ignored with public static {} blocks

The following produces an error for conflicting constructors, "Previous Definition Different". class Foo { public static { this() {} } public { this() {} } } Remove the curly braces from the public static and it compiles fine. With anything defined or declared in a public static block, the static attribute is ignored. I'm sure this used to work, once upon a time. Tested on 2.052 only.

(In reply to comment #0) > The following produces an error for conflicting constructors, "Previous > Definition Different". > I'm sure this used to work, once upon a time. No. It failed even on DMD 0.140 (Nov 2005).

This bug also happens without "public" for static ctors: class A { static { int x; // this is OK, interpreted as "static int x" this() { ... } // this is NOT OK, interpreted as non-static this() } }

Not a bug. Spec sez: "The static in the static constructor declaration is not an attribute, it must appear immediately before the this"

So the right syntax is: class A { static { ... static this() { ... } ... } } ? Or alternatively class A { static { ... } static this() { ... } } ?

(In reply to comment #3) > Not a bug. Spec sez: > > "The static in the static constructor declaration is not an attribute, it must > appear immediately before the this" Then is it better for the compiler to give an compile-time error for code like this? Is this material for a diagnostic enhancement request? class A { static { this() { ... } } }

I don't think there's anything wrong with the current setup.

There's nothing technically wrong with it, but it's misleading. When you write: class A { int x; this(int) { ... } static { int y; this(uint) { ... } } } It appears as though the second ctor is somehow "static" in some sense, yet it is not, as the current semantics mean that you can hoist it out of the static block and still retain the same meaning. Since that's the case, why not prohibit it from being placed in a static block in the first place?

Invalid attributes are usually ignored in D rather than resulting in an error. So, it's quite consistent that if static {} has no effect on a constructor, the compiler wouldn't complain about you putting a constructor within the static block. Now, whether it's _desirable_ that D function that way is another matter - in general, IMHO it's definitely a negative that invalid attributes get ignored rather than resulting in errors - but it's definitely consistent with the rest of the language.

(In reply to comment #7) > There's nothing technically wrong with it, but it's misleading. I think here there's material for a diagnostic enhancement request. (In reply to comment #8) > Invalid attributes are usually ignored in D rather than resulting in an error. And this is so wrong that it must change. I have zero doubts about this.

Yeah, invalid attributes should not be ignored. They should always generate a compile-time error. Just as expressions with no side-effects generate an error when they appear as standalone statements, rather than get ignored.

There are arguments for it which relate to generic programming. It's not that hard to end up with templated code that would have issues compiling if the compiler errored out on invalid attributes for particular instantiations of a template while being fine for others. I agree that ideally the compiler would error out on invalid attributes, but I think that the situation and its effects have to be closely examined before changing the status quo. Regardless of that though, the big problem is convincing Walter. Personally, I'm surprised that the compiler allows invalid attributes in the first place. I have no idea what his thought process was in allowing them and have no idea what it would take to convince him.

(In reply to comment #11) It's to do with the way the compiler handles attributes. There are four kinds: 1. shared void func(); 2. shared: void func(); 3. shared { void func(); } 4. void func() shared; The first two really evaluate to the third. It doesn't make sense for the third one to give an error on invalid attributes, as they might be intended to a bunch of different declarations. While the first one looks like is should be rejected sometimes, to the compiler they're all the same. The fourth case is special, in that the storage classes get passed directly to the function declaration. There is potential here for rejecting invalid storage classes, but are there any that are actually invalid? So to answer your question: Having attributes work this way make the parser compiler simpler. The decision most likely dates from a time when this was one of D's major goals.

(In reply to comment #12) > So to answer your question: Having attributes work this way make the parser > compiler simpler. The decision most likely dates from a time when this was one > of D's major goals. Then the parser has to be updated and improved to help the poor programmers.

(In reply to comment #9) > (In reply to comment #7) > > There's nothing technically wrong with it, but it's misleading. > > I think here there's material for a diagnostic enhancement request. See issue 7443