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



--- Comment #10 from hsteoh@quickfur.ath.cx 2012-01-27 21:12:58 PST ---
Yeah, invalid attributes should not be ignored. They should always generate a compile-time error. Just as expressions with no side-effects generate an error when they appear as standalone statements, rather than get ignored.

-- 
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=5868



--- Comment #11 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-01-27 21:24:48 PST ---
There are arguments for it which relate to generic programming. It's not that hard to end up with templated code that would have issues compiling if the compiler errored out on invalid attributes for particular instantiations of a template while being fine for others.

I agree that ideally the compiler would error out on invalid attributes, but I think that the situation and its effects have to be closely examined before changing the status quo. Regardless of that though, the big problem is convincing Walter. Personally, I'm surprised that the compiler allows invalid attributes in the first place. I have no idea what his thought process was in allowing them and have no idea what it would take to convince him.

-- 
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=5868


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com


--- Comment #12 from yebblies <yebblies@gmail.com> 2012-01-28 16:40:00 EST ---
(In reply to comment #11)

It's to do with the way the compiler handles attributes.  There are four kinds:

1. shared void func();
2. shared: void func();
3. shared { void func(); }
4. void func() shared;

The first two really evaluate to the third.  It doesn't make sense for the third one to give an error on invalid attributes, as they might be intended to a bunch of different declarations.  While the first one looks like is should be rejected sometimes, to the compiler they're all the same.

The fourth case is special, in that the storage classes get passed directly to the function declaration.  There is potential here for rejecting invalid storage classes, but are there any that are actually invalid?

So to answer your question: Having attributes work this way make the parser compiler simpler.  The decision most likely dates from a time when this was one of D's major goals.

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