www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3118] New: Need a clear spec on how inapplicable attributes are handled

reply d-bugmail puremagic.com writes:
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: -------
Jun 30 2009
next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Nov 09 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3118






 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: -------
Nov 10 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3118




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: -------
Nov 10 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3118






 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: -------
Feb 22 2011