[Issue 18757] static invariant{} should either work or not be valid syntax

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=18757

Jonathan M Davis <issues.dlang at jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang at jmdavisProg.co
                   |                            |m

--- Comment #5 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
(In reply to FeepingCreature from comment #2)
> In case 1, I maintain that this is a bug - the compiler should not
> smile-and-nod while silently ignoring syntax that hints at a semantic that
> does not apply.

The reality of the matter is that the compiler ignores attributes like statict
all over the place (e.g. static on most things at module scope is allowed and
ignored, and you can do something like put @safe on a member variable without
complaint from the compiler). If anything, it's extremely typical for the
compiler to ignore attributes that don't apply rather than to treat them as an
error. In some ways, this can be annoying, but it does help avoid problems in
generic code. So, whether an error should be given in this particular case and
not others is up for debate, but it's par for the course around here.

(In reply to RazvanN from comment #4)
> What about object that have static fields? If you have a static function
> which modify static fields? I would argue that an invariant might want to
> check whether a static function has modified the state of the object.

We could certainly add a feature like that, but it's certainly not what
invariant was designed for. Its purpose was specifically to verify the state of
an object, and arguably, the static fields of an object aren't any different
from those at module-sope except for the fact that they're scoped to be inside
a struct or class. And as such, having an invariant for them would be pretty
weird and is of pretty debatable value. If we went down that route, the
question would become why we don't have module-level invariants.

--