Jump to page: 1 2
Thread overview
[Issue 7724] New: 'final:' doesn't work
Mar 18, 2012
Manu
Apr 21, 2012
SomeDude
Apr 21, 2012
Manu
Apr 21, 2012
Dejan Lekic
Apr 21, 2012
Stewart Gordon
Apr 21, 2012
Manu
Apr 21, 2012
Dejan Lekic
Apr 21, 2012
Manu
Apr 21, 2012
SomeDude
Apr 21, 2012
Manu
Apr 21, 2012
Bernard Helyer
Apr 21, 2012
Stewart Gordon
Apr 22, 2012
Manu
[Issue 7724] 'final:' causes error if any variable declarations are placed between it and the end of its scope
Apr 23, 2012
Stewart Gordon
Apr 24, 2012
Walter Bright
Apr 24, 2012
Manu
Apr 24, 2012
Stewart Gordon
Feb 04, 2013
Andrej Mitrovic
March 18, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7724

           Summary: 'final:' doesn't work
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: critical
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: turkeyman@gmail.com


--- Comment #0 from Manu <turkeyman@gmail.com> 2012-03-18 05:55:52 PDT ---
Placing 'final:' at the top of a class produces many of these:
Error: variable demu.memmap.MemoryRange.name final cannot be applied to
variable

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 18, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7724


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #1 from bearophile_hugs@eml.cc 2012-03-18 05:57:58 PDT ---
It seems it's working too much :-)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
April 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7724


SomeDude <lovelydear@mailmetrash.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lovelydear@mailmetrash.com


--- Comment #2 from SomeDude <lovelydear@mailmetrash.com> 2012-04-21 07:01:54 PDT ---
Where is it said in the spec that this should be possible ?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
April 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7724



--- Comment #3 from Manu <turkeyman@gmail.com> 2012-04-21 07:06:33 PDT ---
(In reply to comment #2)
> Where is it said in the spec that this should be possible ?

As I've been lead to believe, final shouldn't be applicable to data members. Apparently the reason you can't use 'final:' (because it complains when it encounters a variable) is a remnant of D1.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
April 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7724


Dejan Lekic <dejan.lekic@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dejan.lekic@gmail.com


--- Comment #4 from Dejan Lekic <dejan.lekic@gmail.com> 2012-04-21 07:30:33 PDT ---
This is not a bug - you can't use final with variables.

Examine following D2 code:

import std.stdio;

class Issue7724 {
/+--------------------------+
 | Uncomment to get "...someValue final cannot be applied to variable" error.
  final:
    int someValue;
    int setValue(int argValue) { someValue = argValue; }
    int getValue() { return someValue; }
 +--------------------------+/

  // Correct:
  int someValue;
  final:
    void setValue(int argValue) { someValue = argValue; }
    int getValue() { return someValue; }
}

int main() {
  return 0;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
April 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7724


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com


--- Comment #5 from Stewart Gordon <smjg@iname.com> 2012-04-21 08:58:12 PDT ---
The debate is one of whether an attribute specified with the colon syntax is meant to apply to _everything_ that follows it until the end of the scope, or only those members to whose entity type it is applicable.  When I filed issue 3118, I argued that the latter is reasonable.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
April 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7724



--- Comment #6 from Manu <turkeyman@gmail.com> 2012-04-21 09:39:11 PDT ---
(In reply to comment #4)
> This is not a bug - you can't use final with variables.
> 
> Examine following D2 code:
> 
> import std.stdio;
> 
> class Issue7724 {
> /+--------------------------+
>  | Uncomment to get "...someValue final cannot be applied to variable" error.
>   final:
>     int someValue;
>     int setValue(int argValue) { someValue = argValue; }
>     int getValue() { return someValue; }
>  +--------------------------+/
> 
>   // Correct:
>   int someValue;
>   final:
>     void setValue(int argValue) { someValue = argValue; }
>     int getValue() { return someValue; }
> }
> 
> int main() {
>   return 0;
> }

It's inconsistent to allow superfluous instance of some attributes, but not others.

static int x; at global scope is silently ignored.
final applied to data members should be equally ignored, but rather, attributes
with colon probably just shouldn't be applied to things that they're not
applicable to. Otherwise you'll end up with all sorts of class organisation
mess when you consider a few attributes together.

I'm not into the idea that the language should insist I break my class up according to arbitrary attributes, rather than keeping related things together, which I find far preferable.

Also, declaring 'final:' at some arbitrary point in a class is hard to spot, and error prone (it might be missing). If it's the first thing in a class (like 'public:' often is in C++), then it's very easy to spot and validate.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
April 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7724



--- Comment #7 from Dejan Lekic <dejan.lekic@gmail.com> 2012-04-21 10:28:29 PDT ---
@Manu:
I see your point.
However, I disagree - one should learn the language, and understand where and
how "final:" can be used. I have no problems with the current situation.
Compiler also generates a helpful error message that can be understood by
anyone. I personally never use public: final: private: etc... I prefer
public{}, private{}, etc. or use these per-declaration.

@Stewart Gordon
Neither are good - the second approach makes it possible to easily make a
mistake if developer is not pedantic enough. Say a class has buch of various
methods - and in the middle of it developer decides to add a variable... I know
- bad programming practice but still possible... However, developers typically
group variables and methods, so I guess it is OK.

As I said, I like the current approach when compiler generates a descriptive error.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
April 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7724



--- Comment #8 from Manu <turkeyman@gmail.com> 2012-04-21 11:30:09 PDT ---
(In reply to comment #7)
> @Manu:
> I see your point.
> However, I disagree - one should learn the language, and understand where and
> how "final:" can be used. I have no problems with the current situation.
> Compiler also generates a helpful error message that can be understood by
> anyone. I personally never use public: final: private: etc... I prefer
> public{}, private{}, etc. or use these per-declaration.

I think it's safe to say that the preference of keeping associated stuff together is nothing to do with learning the language or not. This is culture, taste, and company standards.

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. It's only final that complains, and that's very annoying, because it's the only one I'm passionately insistent about.

I'd like to think it should be fixed to be consistent with all the others for consistency's sake alone. Making me happy would be a nice side effect :)


From a subjective point of view, I don't like the introduction of an extra indentation level by attribute{}, and why supply 2 ways if not to support user preference?

I'd prefer the language forcefully dictate how I arrange my code as little as possible. 95% of functions are final, and as such, for us, it should always be within the first couple of lines in the class.

It would be a company policy that it were the first line in every class if I could explicitly state virtual. However as is now, we ideally declare 1-2 virtuals, then final:, and then everything else, with the class laid out however is most naturally readable, and logical to follow.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
April 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7724



--- Comment #9 from SomeDude <lovelydear@mailmetrash.com> 2012-04-21 12:21:57 PDT ---
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".

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
« First   ‹ Prev
1 2