www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3934] New: Some untidy attributes

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934

           Summary: Some untidy attributes
           Product: D
           Version: 2.041
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Keywords: accepts-invalid, rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



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).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 11 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 14 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 30 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




This too is wrong (this compiles with dmd v2.047):


struct Foo {
    static invariant() {}
}
void main() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 15 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




One from Leopold Walkling, this compiles:

auto void main() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 30 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 30 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 25 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




From Simen kjaeraas:

__gshared struct foo {
    int n;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 17 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




From bernardh on IRC, this program compiles:

auto scope shared import std.stdio;
void main() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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();
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 21 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 05 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934






class Foo {}
public class Test : Foo {
    public static void Main() {}
}



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() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 08 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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'

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 08 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934






 This bug is now fixed:




-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 08 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934






 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)[] .


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 23 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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'

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 19 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934






 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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934


klickverbot <code klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code klickverbot.at



---




 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. ;)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934










 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934






 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




By mleise on IRC #D:


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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 08 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 08 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




Found by Ellery Newcomer:

alias enum int e;
void main() {}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 08 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3934




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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 07 2012