Thread overview
[Issue 9853] New: The order of static and shared on module constructors matters when it shouldn't
Apr 02, 2013
Jonathan M Davis
Apr 02, 2013
Kenji Hara
Apr 02, 2013
Jonathan M Davis
Apr 02, 2013
Kenji Hara
April 02, 2013
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


--- Comment #0 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-04-01 18:36:12 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: -------
April 02, 2013
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


--- Comment #1 from Kenji Hara <k.hara.pg@gmail.com> 2013-04-01 19:19:26 PDT ---
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: -------
April 02, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9853



--- Comment #2 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-04-01 22:27:42 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: -------
April 02, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9853



--- Comment #3 from Kenji Hara <k.hara.pg@gmail.com> 2013-04-01 22:46:28 PDT ---
(In reply to comment #2)
> 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: -------