[Issue 7724] 'final:' causes error if any variable declarations are placed between it and the end of its scope
http://d.puremagic.com/issues/show_bug.cgi?id=7724 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||DUPLICATE --- Comment #18 from Andrej Mitrovic andrej.mitrov...@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: ---
[Issue 7724] 'final:' causes error if any variable declarations are placed between it and the end of its scope
http://d.puremagic.com/issues/show_bug.cgi?id=7724 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Severity|critical|enhancement --- Comment #15 from Walter Bright bugzi...@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: ---
[Issue 7724] 'final:' causes error if any variable declarations are placed between it and the end of its scope
http://d.puremagic.com/issues/show_bug.cgi?id=7724 --- Comment #17 from Stewart Gordon s...@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: ---
[Issue 7724] 'final:' causes error if any variable declarations are placed between it and the end of its scope
http://d.puremagic.com/issues/show_bug.cgi?id=7724 Stewart Gordon s...@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 s...@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: ---
