Bug 3934 – Some untidy attributes

This D2 program compiles and runs with no errors or warnings: static foo1() {} final foo2() {} ref foo3() {} enum void foo4() {} nothrow foo5() {} pure foo6() {} static int x1 = 10; static x2 = 10; void main() {} Notes: - foo1, x1, x2: I don't know what a static global void function/variable is in D2, so 'static' can be disallowed for global functions/variables. - foo2, foo3, foo4: they look like bugs. - Are most of those attributes supposed to not need the "void"? I think requiring for example "pure void" is a little better than allowing just "pure". The following lines don't compile, is this correct? int static x3 = 10; int enum x4 = 1; int const x5 = 2; I like the strictness of the Java compiler, it makes sure your attributes are all correct and meaningful, this helps avoid possible bugs. And I'm sure it helps newbies learn the language in less time too (because when you don't know the rules yet, it's very useful if they don't change).

A person in the IRC channel suggests that this too can be bad (this program compiles and runs with dmd 2.043): extern struct foo; void main() {}

This seems to be partly a duplicate of issue 3118. Without a clear spec on the matter, it's hard to decide which of these it's a bug that the compiler accepts, but certainly foo3 and foo4 AISI.

This too is wrong (this compiles with dmd v2.047): struct Foo { static invariant() {} } void main() {}

One from Leopold Walkling, this compiles: auto void main() {}

I certainly call that a bug. Partly a consequence of auto being an attribute rather than a placeholder for a type, though this seems to be partly for backward compatibility with the old meaning of auto. Either way, it's an inapplicable attribute and one that ought not to be accepted.

Two more related cases: This looks correct: auto main() { return 0; } But dmd 2.047 prints: test.d(1): Error: function D main must return int or void ---------------- The error message shows that foo() is not pure: test.d(5): Error: pure function 'bar' cannot call impure function 'foo' auto pure foo() { return 1; } pure void bar() { foo(); } void main() {} So it seems 'pure' is ignored if 'auto' is present.

From Simen kjaeraas: __gshared struct foo { int n; }

From bernardh on IRC, this program compiles: auto scope shared import std.stdio; void main() {}

This D2 program compiles and runs with DMD 2.048 with no errors, but I think the compiler has to flag this usage of the 'private final' attributes as incorrect: import std.c.stdio: puts; class Base { private final ~this() { puts("Base.~this"); } } class Derived : Base { private final ~this() { puts("Derived.~this"); } } void main() { new Derived(); }

Structs can't be subclassed, so protected struct fields seem a bug. This compiles with dmd 2.049: struct Foo { protected int x; } void main() {}

This compiles with no errors with dmd 2.049, but I'd like a compile-time error similar to "manifest constants are always static": void foo() { static enum x = 10; } void main() {}

See the closed bug 5171 for code that may be disallowed statically: class A { @disable override equals_t opEquals(Object other) { return false; } } void main() { auto a = new A(); auto b = new A(); if(a == b) assert(0); }

This is C# code: class Foo {} public class Test : Foo { public static void Main() {} } The C# compiler gives this error: prog.cs(2,14): error CS0060: Inconsistent accessibility: base class `Foo' is less accessible than class `Test' While the D 2.050 compiler gives no errors with this code: private class Foo {} public class Bar : Foo {} void main() {}

This bug is now fixed: auto pure foo() { return 1; } pure void bar() { foo(); } void main() {} DMD 2.050 gives the error: test.d(5): Error: pure function 'bar' cannot call impure function 'foo'

(In reply to comment #14) > This bug is now fixed: Ignore comment #14, the bug is not fixed, sorry.

This shows something strange, dmd 2.051: const struct Foo1 { int* p; } struct Foo2 { int* p; } void bar1(Foo1 f1) {} void bar2(Foo2 f2) {} void main() { const f1 = Foo1(); bar1(f1); // no error const f2 = Foo2(); bar2(f2); // error }

(In reply to comment #16) > This shows something strange, dmd 2.051: According to Mafi that code is correct: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=24058 > I think it's absolutely correct. Look: Foo3 is declared as const > struct meaning all it's members are const. We are passing a struct > like that to bar3: > const Foo3 { const int* p} > which is implicitely converted to: > Foo3 { const int* p } //not ref !! > Because it's not ref you can't manipulate the original struct anyways > and the pointer is still const. As long as you don't cast you cannot > change what the pointer points to so this implicit conversion is > correct IMO. > It's like const(T[]) => const(T)[] .

Another variant of the code, found by Dan Olson, this compiles and runs with no errors with DMD 2.051: struct Foo { int x; } void bar(ref Foo f) { f.x = 1; } void main() { const f = Foo(); bar(f); }

It seems "emum" implies "static": enum X = 10; void main() { enum int X = 20; static int foo() { return X; // No errors } assert(foo() == 20); // No errors } Yet this compiles: void main() { enum static int x = 1; } While this: void main() { static static int x = 1; } Produces the error: test.d(2): redundant storage class 'static'

This is accepted by DMD 2.054, but if it's not meaningful in D then I suggest to statically disallow it, as the other examples: class Foo {} class Bar : public Foo {} void main() {}

(In reply to comment #20) > This is accepted by DMD 2.054, but if it's not meaningful in D then I suggest > to statically disallow it, as the other examples: > > class Foo {} > class Bar : public Foo {} > void main() {} There are no attributes as such in your example. And I don't see anything that isn't meaningful. So what do you mean?

(In reply to comment #21) > (In reply to comment #20) > > class Foo {} > > class Bar : public Foo {} > > void main() {} > > There are no attributes as such in your example. And I don't see anything that > isn't meaningful. So what do you mean? I think bearophile is referring to the »public« protection attribute in the SuperClass. This is explicitly allowed by the grammar, but I don't know off hand if it actually has any effect in the current implementation, other than giving C++ programmers a wrong sense of coziness maybe. ;)

(In reply to comment #22) > (In reply to comment #21) >> (In reply to comment #20) >>> class Foo {} >>> class Bar : public Foo {} >>> void main() {} >> >> There are no attributes as such in your example. And I don't see >> anything that isn't meaningful. So what do you mean? > > I think bearophile is referring to the »public« protection attribute in the > SuperClass. This is explicitly allowed by the grammar, but I don't know off > hand if it actually has any effect in the current implementation, other than > giving C++ programmers a wrong sense of coziness maybe. ;) Therein lies my point - it isn't an attribute as such, and it isn't meaningless. It means the same as in C++, though it doesn't make sense to have the feature in D. But this point is covered by issue 177.

(In reply to comment #20) > This is accepted by DMD 2.054, but if it's not meaningful in D then I suggest > to statically disallow it, as the other examples: > > > class Foo {} > class Bar : public Foo {} > void main() {} Bug 177, Bug 5299.

By mleise on IRC #D: struct Foo { void bar() const const const {} } void main() {}

By mleise on IRC #D: class Base { abstract void foo(); } class Ext : Base { override void foo(); // override should require an implementation } void main() {} If uncaught by the compiler this causes a linker error.

Found by Ellery Newcomer: alias enum int e; void main() {}

struct Foo { protected void bar() {} } void main() {}

There are way too many examples (some of which have been addressed, many still valid) for this to be actionable. A proper proposal would most likely take a lot of time and go through the DIP process, as it is a fundamental change to the grammar (regardless of its validity). Trivial items such as protection attributes on class inheritance and redundant attributes have been addressed. Some items are also documented here: https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d > I like the strictness of the Java compiler, it makes sure your attributes are all correct and meaningful, this helps avoid possible bugs. To address this specific point: DMD being lax, while unsettling to some, is also great for generic code. There are quite a lot of cases where DMD being stricter would result in worst code because it would require some special casing in generic code. Closing as INVALID.