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



--- Comment #10 from Manu <turkeyman@gmail.com> 2012-04-21 12:30:41 PDT ---
(In reply to comment #9)
> I'm not fond of the C++ syntax either. But it's a matter of taste, I guess.
> 
> Either way, unless you can point it in the spec, I think this issue should be reduced from "critical" to "enhancement".

It's clearly a bug. All other attributes work as expected. This is the odd one out.

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


Bernard Helyer <blood.of.life@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |blood.of.life@gmail.com


--- Comment #11 from Bernard Helyer <blood.of.life@gmail.com> 2012-04-21 12:34:19 PDT ---
Seeing as DMD ignores most no-op attributes, I have no idea why this is the one where it suddenly decides that it should generate an error. I think final on variables should just be ignored, in keeping with other attributes.

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



--- Comment #12 from Stewart Gordon <smjg@iname.com> 2012-04-21 16:38:03 PDT ---
(In reply to comment #8)
> I need to reiterate the consistency issue.  Other superfluous attributes appear to be silently ignored where they are not applicable.  __gshared makes no sense on a function, but it doesn't complain, as is static, shared, immutable, etc.

By "superfluous", do you mean "redundant" or "not making sense in the context"?
 This is an important distinction to consider.

(In reply to comment #10)
> It's clearly a bug. All other attributes work as expected.

Not sure what you mean by that....

(In reply to comment #11)
> Seeing as DMD ignores most no-op attributes, I have no idea why this is the one where it suddenly decides that it should generate an error.  I think final on variables should just be ignored, in keeping with other attributes.

What particular "other attributes" are you talking about?

Thinking about it now, variables can't be overridden, and so essentially are already final.  Banning them from being declared final might be considered silly on this basis.  So final on member variables is redundant, as opposed to (for example) __gshared on functions which doesn't make sense.

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



--- Comment #13 from Manu <turkeyman@gmail.com> 2012-04-22 04:02:16 PDT ---
(In reply to comment #12)
> (In reply to comment #8)
> > I need to reiterate the consistency issue.  Other superfluous attributes appear to be silently ignored where they are not applicable.  __gshared makes no sense on a function, but it doesn't complain, as is static, shared, immutable, etc.
> 
> By "superfluous", do you mean "redundant" or "not making sense in the context"?
>  This is an important distinction to consider.

Both are true for other attributes. __gshared makes no sense applied to a function, static applied at the global scope however is at least redundant, maybe both.

I think it depends how you look at it. The colon syntax isn't really an explicit application of an attribute to everything that follows (at least, it doesn't seem to be that way for all other attributes at this time). The policy already seems to be be defined as applying the attribute only those items it is applicable to, the only exclusion at this time seems to be final.


> (In reply to comment #10)
> > It's clearly a bug. All other attributes work as expected.
> 
> Not sure what you mean by that....

'__gshared:' doesn't cause errors, neither does 'immutable:', or any others I tried. They all have cases where they are not applicable, but they are silently ignored, as final should be.


> (In reply to comment #11)
> > Seeing as DMD ignores most no-op attributes, I have no idea why this is the one where it suddenly decides that it should generate an error.  I think final on variables should just be ignored, in keeping with other attributes.
> 
> What particular "other attributes" are you talking about?

shared, __gshared, immutable at least.


> Thinking about it now, variables can't be overridden, and so essentially are already final.  Banning them from being declared final might be considered silly on this basis. So final on member variables is redundant,

Excellent point :)

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


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec
            Summary|'final:' doesn't work       |'final:' causes error if
                   |                            |any variable declarations
                   |                            |are placed between it and
                   |                            |the end of its scope


--- Comment #14 from Stewart Gordon <smjg@iname.com> 2012-04-23 02:05:59 PDT ---
(In reply to comment #13)
> I think it depends how you look at it.  The colon syntax isn't really an explicit application of an attribute to everything that follows (at least, it doesn't seem to be that way for all other attributes at this time).

That's indeed the point I was making in comment 5.

> The policy already seems to be be defined as applying the attribute only those items it is applicable to, the only exclusion at this time seems to be final.

But it's generally doing this with all ways of applying an attribute, not just the colon syntax.

>>> It's clearly a bug.  All other attributes work as expected.
>> 
>> Not sure what you mean by that....
> 
> '__gshared:' doesn't cause errors, neither does 'immutable:', or any others I tried.  They all have cases where they are not applicable, but they are silently ignored, as final should be.

So in your mind, if the compiler just ignored an ExpressionStatement that is a call to an undefined function (skipped over it without generating any code), this would constitute the call working? :)

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


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com
           Severity|critical                    |enhancement


--- Comment #15 from Walter Bright <bugzilla@digitalmars.com> 2012-04-24 11:53:49 PDT ---
The compiler behavior here is obviously deliberate, so this isn't a bug but an enhancement request.

'final' in Java for a variable means it is assigned once in the constructor, and never again. The equivalent is achieved in D using 'const' and not supplying an initializer.

'final' in D1 has similar semantics to Java.

The reason 'final' applied to fields in D2 is an error is so that the user transferring code from D1 to D2 will be notified of changes required, rather than silently breaking his code.

Silently breaking code is very, very bad. There are still a lot of D users who are moving from D1 to D2, and while that's going on I don't think implementing this is a good idea.

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



--- Comment #16 from Manu <turkeyman@gmail.com> 2012-04-24 13:36:22 PDT ---
(In reply to comment #15)
> Silently breaking code is very, very bad. There are still a lot of D users who are moving from D1 to D2, and while that's going on I don't think implementing this is a good idea.

Fair enough. Are there other instances of treatment of this sort?
Perhaps a compiler switch that enables warnings for D1->D2 porting, similar to
how many x32 compilers make noise about 64bit portability issues?

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



--- Comment #17 from Stewart Gordon <smjg@iname.com> 2012-04-24 13:51:22 PDT ---
(In reply to comment #15)
> 'final' in Java for a variable means it is assigned once in the constructor, and never again. The equivalent is achieved in D using 'const' and not supplying an initializer.
> 
> 'final' in D1 has similar semantics to Java.

I can't see it anywhere in the D1 docs as anything other than an attribute applied to methods to prevent them being overridden.  I had made out that Java's meaning of final on fields just didn't exist in D, what with D having const for things like that.

Moreover, given that "final" was overloaded to denote two very different attributes, it would seem silly that a single use of the word could apply both these attributes.  But if people actually did it....

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


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |andrej.mitrovich@gmail.com
         Resolution|                            |DUPLICATE


--- Comment #18 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-02-04 14:06:55 PST ---
*** This issue has been marked as a duplicate of issue 7071 ***

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