[Issue 9853] The order of static and shared on module constructors matters when it shouldn't

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9853



--- Comment #3 from Kenji Hara <k.hara.pg at 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: -------