Bug 6415 – Placement of pure and nothrow for invariant()

This code shows a problem with placement of pure and nothrow: class Foo { pure nothrow invariant() {} // OK invariant() pure nothrow {} // Error } void main() {} DMD 2.054 gives: test.d(3): statement expected to be { }, not pure test.d(3): basic type expected, not { test.d(3): no identifier for declarator int test.d(3): semicolon expected, not '{' test.d(3): Declaration expected, not '{' test.d(5): } expected following member declarations in aggregate

(In reply to comment #0) > This code shows a problem with placement of pure and nothrow: > > class Foo { > pure nothrow invariant() {} // OK > invariant() pure nothrow {} // Error > } > void main() {} Today `invariant {}` is parsed same as `immutable {}` (= `AttributeDeclaration`), because in early D2 age `invariant` had been reused for `immutable` meaning. So `invariant` block requires following `()` to keep backward compatibility. But, eventually the redundant parenthesis would be unnecessary, and you can write invariant block as same as unittest block. And, currently unittest block does not accept postfix attributes. ```d invariant() @pure safe nothrow {} // allwed by this change invariant @pure safe nothrow {} // eventually allowed? unittest @pure safe nothrow {} // currently not allowed ``` Therefore, just only fixing invariant syntax will introduce future inconsistency. So we should consider unittest block syntax at the same time.

I'm not convinced anything needs fixing. Why should: invariant() pure nothrow { } be accepted? After all, as Kenji mentioned, the () is to support old code and will eventually go away anyway.

So this means that ideally the grammar would be: invariant: 'invariant' blockStatement ; correct?

(In reply to comment #3) > After all, as Kenji mentioned, the () is to support old code and > will eventually go away anyway. OK. dmd 2.064 is a good moment for that "eventually" to be, see Issue 10326

(In reply to comment #1) > https://github.com/D-Programming-Language/dmd/pull/2156 Given the recent comments by Walter and Kenji, the two years of Walter's total silence passed since this proposal, and the changes proposed in Issue 10326 , then maybe this whole issue becomes useless. Do we want to write code like this? class Foo { invariant pure nothrow {} } unittest pure nothrow {} void main() {} It's not a good change. So please let me close this issue down. If someone wants to press the issue further then please reopen this issue.