www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9853] New: The order of static and shared on module constructors matters when it shouldn't

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

           Summary: The order of static and shared on module constructors
                    matters when it shouldn't
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: jmdavisProg gmx.com



PDT ---
This code

static shared this()
{
}

void main()
{
}

fails to compile, giving this error:

q.d(1): Error: constructor q.this constructors are only for class or struct
definitions

whereas if the static and shared are swapped, it compiles just fine. The order
shouldn't matter.

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


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID



This is by design.

http://dlang.org/class.html#StaticConstructor


 The **static** in the static constructor declaration is not an attribute,
 it must appear immediately before the this:

 class Foo {
   static this() { ... } // a static constructor
   static private this() { ... } // not a static constructor
   static {
     this() { ... }      // not a static constructor
   }
   static:
     this() { ... }      // not a static constructor
 }


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




PDT ---
Well, that seems incredibly arbitrary, and I have no idea how anyone could
claim that static isn't an attribute. It's as much an attribute as const or
shared is.

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






 Well, that seems incredibly arbitrary, and I have no idea how anyone could
 claim that static isn't an attribute. It's as much an attribute as const or
 shared is.


I think that the limitation comes from current D parser.

Current D parser does not distinguish `static: void foo(){}` and `static void
foo(){}`. 

struct S { pure void foo() {} }

is parsed as:

struct S {
    pure { void foo() {} }
}

There is no "prefixed attribute".
But, for static constructor, applying same mechanism is dangerous.

struct S {
  static {
    this() {}  // accidentally makes static constructor.
  }
}

I think that is why special rule exists for static constructor.

---

Similar problem is in prefixed const and member function.

struct S {
  const int foo() {}  // const method foo, returns mutable int
  const: int bar() {}  // const method bar, returns mutable int
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 01 2013