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

           Summary: Need a clear spec on how inapplicable attributes are
                    handled
           Product: D
           Version: 1.045
          Platform: All
               URL: http://www.digitalmars.com/d/archives/digitalmars/D/Th
                    e_great_inapplicable_attribute_debate_87915.html
        OS/Version: All
            Status: NEW
          Keywords: spec
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: smjg@iname.com
            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
attribute:
(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
attributes

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: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |WONTFIX


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2010-11-09 23:41:33 PST ---
i, ii, and iii are equivalent as documented. I think that should remain, as it would be very confusing to make them behave differently. Not sure what you mean by iv.

Other problems with inappropriate attributes should be handled on a case by case basis. I don't think a general policy will work.

Therefore, I'll mark this as wontfix, with the supposition that the various cases should each have their one bugzilla entry.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #2 from Stewart Gordon <smjg@iname.com> 2010-11-10 04:35:28 PST ---
(In reply to comment #1)
> i, ii, and iii are equivalent as documented. I think that should remain, as it would be very confusing to make them behave differently.

Not sure what you mean by this.

> Not sure what you mean by iv.

I figured that there might be cases (such as align) where applying the attribute to a class, struct, etc. applies it to each of its members.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2010-11-10 11:16:26 PST ---
attribute int a;
attribute: int a;
attribute { int a; }

should all have the same meaning for a.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #4 from Stewart Gordon <smjg@iname.com> 2011-02-22 16:11:49 PST ---
(In reply to comment #3)
> attribute int a;
> attribute: int a;
> attribute { int a; }
> 
> should all have the same meaning for a.

This whole debate is about legality, not meaning.  Defining that they always all have the same legality erodes the usefulness of the colon notation especially, since one could try to use it and then be forced to move a declaration to which it doesn't make sense to above the attribute, which can get annoying if you want to place declarations in some intuitive or logical order.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------