Summary: Need a clear spec on how inapplicable attributes are
           Product: D
           Version: 1.045
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: spec
          Severity: normal
          Priority: P2
         Component: DMD
            Blocks: 677

If one tries to apply an argument to an entity to which it is not applicable,
how is the compiler supposed to deal with the attempt?  There has been
considerable debate about it both here on Bugzilla and on the newsgroups, and
the anomalies have been widely observed.

The compiler, under certain conditions, silently ignores such inapplicable
attributes.  It isn't clear what these conditions are, and there are some
conditions under which it should certainly not be happening.

There are three kinds of inapplicability to consider:
(a) attribute's meaning already implied by the context
(b) doesn't make sense in the context
(c) makes sense in the context but is nonetheless not actually applied.

Issue 1441 (later resurfaced as issue 2830) is a prime example of (c).  That
any cases of (c) actually exist is bad in itself.

We need a clear spec on the whole issue.  It should consider not only the three
kinds of inapplicability, but also the possible ways of specifying an
(i) directly to the declaration
(ii) using { }
(iii) using :
(iv) inherited by the members of a compound type, in the case of one or two

AISI the most lenient policy that is reasonable is:
- allow (a) always
- allow (b) except when applied by (i)
- eradicate all cases of (c) by fixing the affected attributes to work

Whatever we do, both the spec and the compiler will need to be amended.

Further discussion at URL given.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to