www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Implicit const

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
One of the more annoying things about C++ (and current D2) is that calls 
to functions fail to compile if the designer hasn't given const much 
thought.  Example:

class Class {
    int getA() { return a_; }
private:
    int a_;
}

getA could easily be made
     int getA() const { return a_; }
but the class writer just didn't think of it.

However, when the compiler compiles getA, it can actually tell pretty 
easily, that, yeh, getA is really also OK as const.  So at least for 
such simple cases, it seems that the explicit labeling is not really 
necessary.  Maybe the set of cases where it would work is large enough 
to make this a useful feature.

--bb
Apr 02 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 03/04/2008, Bill Baxter <dnewsgroup billbaxter.com> wrote:

  However, when the compiler compiles getA, it can actually tell pretty
 easily, that, yeh, getA is really also OK as const.  So at least for such
 simple cases, it seems that the explicit labeling is not really necessary.


I've thought about this before, and it seems to me that, if D had
warnings, it would be a good call to issue a warning for any function
which /could/ have declared itself const, but didn't. Ditto any
function parameter.

Similarly,

    class C
    {
        int f()
        {
            return 42;
        }
    }

the compiler is in a position to say "Wait a minute - you could have
declared f static, but didn't".

Again, implicit attributes are not a good idea, because it's a good
idea to have the compiler check that you're enforcing the contract you
claim to be enforcing. But warnings would be useful.

...Not that D has warnings. Maybe it could be a -w feature?
Apr 02 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Janice Caron escribió:

 On 03/04/2008, Bill Baxter <dnewsgroup billbaxter.com> wrote:

  However, when the compiler compiles getA, it can actually tell pretty
 easily, that, yeh, getA is really also OK as const.  So at least for such
 simple cases, it seems that the explicit labeling is not really necessary.


 
 I've thought about this before, and it seems to me that, if D had
 warnings, it would be a good call to issue a warning for any function
 which /could/ have declared itself const, but didn't. Ditto any
 function parameter.
 
 Similarly,
 
     class C
     {
         int f()
         {
             return 42;
         }
     }
 
 the compiler is in a position to say "Wait a minute - you could have
 declared f static, but didn't".


But maybe you want that function to be overriden by subclasses. Maybe if 
it were "final int f()", then it could say that.

What about const? Does a const function must be overriden by a const 
function?
Apr 03 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 03/04/2008, Ary Borenszweig <ary esperanto.org.ar> wrote:

  But maybe you want that function to be overriden by subclasses. Maybe if it
 were "final int f()", then it could say that.

  What about const? Does a const function must be overriden by a const
 function?


I said warning, not error. A warning is not an error. I propose /no/
changes here to legal D. Warnings are an entirely different beast. But
D doesn't have warnings, so the question is moot. Perhaps some
third-party app could be written to emit such warnings, I don't know.
Apr 03 2008
parent reply "Craig Black" <craigblack2 cox.net> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.306.1207222160.2351.digitalmars-d puremagic.com...

 On 03/04/2008, Ary Borenszweig <ary esperanto.org.ar> wrote:

  But maybe you want that function to be overriden by subclasses. Maybe if 
 it
 were "final int f()", then it could say that.

  What about const? Does a const function must be overriden by a const
 function?


 I said warning, not error. A warning is not an error. I propose /no/
 changes here to legal D. Warnings are an entirely different beast. But
 D doesn't have warnings, so the question is moot. Perhaps some
 third-party app could be written to emit such warnings, I don't know.


Just don't issue the warning if the function is overriden.  The compiler 
could be smart enough to do that.
Apr 03 2008
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Craig Black wrote:

 Just don't issue the warning if the function is overriden.  The compiler 
 could be smart enough to do that.


The compiler only looks at the files needed to compile the current 
module, i.e. all modules imported from it (directly or indirectly).
So if a method is only overridden in files not imported from the one 
containing the base class, it has no way of knowing about it...

For example:
----
module a;

class B {
     int foo() { return 42; }
}
----
module b;

import a;

class D : B {
     private int foo_value;
     int foo() { return foo_value; }
}
----
While compiling module 'a' above, the compiler doesn't look at module 
'b', so it won't know about D overriding foo(). Or even that class D 
exists, for that matter.
Apr 03 2008
parent "Craig Black" <craigblack2 cox.net> writes:
"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:ft3ndl$2eqg$1 digitalmars.com...

 Craig Black wrote:

 Just don't issue the warning if the function is overriden.  The compiler 
 could be smart enough to do that.


 The compiler only looks at the files needed to compile the current module, 
 i.e. all modules imported from it (directly or indirectly).
 So if a method is only overridden in files not imported from the one 
 containing the base class, it has no way of knowing about it...

 For example:
 ----
 module a;

 class B {
     int foo() { return 42; }
 }
 ----
 module b;

 import a;

 class D : B {
     private int foo_value;
     int foo() { return foo_value; }
 }
 ----
 While compiling module 'a' above, the compiler doesn't look at module 'b', 
 so it won't know about D overriding foo(). Or even that class D exists, 
 for that matter.


Right.  The D compiler has no way of knowing what functions are virtual 
bases.  But that's actually irrelevant.  Virtual bases aren't the problem. 
It's the override functions that need immunity from this error.  I guess 
what I should have said is:

Just don't issue the warning if the function is overriding another function. 
The compiler could be smart enough to do that.

-Craig
Apr 03 2008