www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - const member function synatx?

reply im <no body.com> writes:
I read the page: http://www.digitalmars.com/d/2.0/const3.html
under section "Const Member Functions"

It didn't give any example, but following the example of 'invariant', it
should be:

const ReturnType memberFunc(param) {}

I think this is really confusing: is 'const' trying to specify the
'ReturnType' or the memberFunc?

And if I want to specify both, then I have to write:

const const ReturnType  memberFunc(param) {}, or
const const(ReturnType) memberFunc(param) {}

The 2 leading const in a row looks ugly and confusing.

Why not just use the C++'s postfix syntax for const member function? to put
'const' after the param, and before the body {}

ReturnType memberFunc(param) const {}

So I tried it (although undocumented); and to my glad, it worked (see code
below).

But there seems to have a semantic bug: I'm modifying class field in void f(A
o) const {...}, but the compiler didn't complain about it.

I think we should fix the confusing syntax, and use C++'s postfix syntax for
const member function; and also fix this bug.


$ cat const.d
===============================
class A{
public:
  A m_a;
}

class B{
public:
  A m_a;
  A a() const {
    return m_a;
  }
  void f(A o) const {  // without 'const' won't compile
    m_a = o;           // BUG, I'm modifying m_a
  }
/*
  const A v() {
    m_a = null;
    return m_a;
  }
*/
}

int main() {
  const B b = new B();

  A a = b.a();
  a.m_a = null;
  b.f(a);
//b.v();

  return 0;
}
===============================
$ dmd.exe const.d
d:\project\dmd\bin\..\..\dm\bin\link.exe const,,,user32+kernel32/noi;
Feb 15 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 15/02/2008, im <no body.com> wrote:

  I think this is really confusing: is 'const' trying to specify the
  'ReturnType' or the memberFunc?

  And if I want to specify both, then I have to write:

  const const ReturnType  memberFunc(param) {}, or
  const const(ReturnType) memberFunc(param) {}


Actually, only

    const const(ReturnType) memberFunc(param) {}

would work.

This has been mentioned before, and for what it's worth, I agree with
you. Just some comments though. Walter likes the existing syntax,
because it means you can do:

    const
    {
        /* several functions */
    }

It is unusual ever to need to return a const(ReturnType), since why
would you want to prevent the callee from modifying their copy of the
return value? That said, it is very common to want to return a
const(T)[] for some T, so the problem doesn't go away.

const-at-the-end syntax does work. I don't know if this is a permanent
feature or not, but currently you can say:

    const(ReturnType) memberFunc(param) const {}

And finally, I have argued in the past (and still believe) that the D
syntax should be

    const(this) const(ReturnType) memberFunc(param) {}

For an extra six characters, you get complete clarity. const(this)
would mean that the symbol "this" will (transitively) not be modified
within its scope. Walter's desire to encompass multiple functions
would thus be preserved. i.e.

    const(this)
    {
        /* several functions */
    }

and in addition, the new syntax lends itself to future expansion (such
as const(outer), etc.). Unfortunately, last I heard, Walter wasn't too
keen on this suggestion, possibly because it means typing six more
characters.

But either way, I definitely believe that

    const ReturnType memberFunc(param) {}

/must/ have exactly one interpretation, and that interpretation should be

    const(ReturnType) memberFunc(param) {}

and not, as is currently the case

    ReturnType memberFunc(param) const {}

I agree that that /is/ confusing, and is one of those little creases
in the new const system that we still need to iron out.
Feb 15 2008
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Janice Caron wrote:

 It is unusual ever to need to return a const(ReturnType), since why
 would you want to prevent the callee from modifying their copy of the
 return value?


How about returning a class reference that you still have your own copy to?
One common example of this might be getters for properties of class 
type, especially if the class instance is part of the internal state of 
the owning class and shouldn't be modified without going through the 
methods of the owner.
Feb 16 2008
parent "Janice Caron" <caron800 googlemail.com> writes:
On 16/02/2008, Frits van Bommel <fvbommel remwovexcapss.nl> wrote:

 Janice Caron wrote:
  > It is unusual ever to need to return a const(ReturnType), since why
  > would you want to prevent the callee from modifying their copy of the
  > return value?


 How about returning a class reference that you still have your own copy to?


Good point. I'd forgotten about that one.

Not that that makes any difference to im's original point, or to my
reply, of course. The unintuitive meaning of

    const ReturnType f(params...)

still remains.
Feb 16 2008
prev sibling parent reply renoX <renosky free.fr> writes:
im Wrote:


 I read the page: http://www.digitalmars.com/d/2.0/const3.html
 under section "Const Member Functions"
 
 It didn't give any example, but following the example of 'invariant', it
 should be:
 
 const ReturnType memberFunc(param) {}
 
 I think this is really confusing: is 'const' trying to specify the
 'ReturnType' or the memberFunc?


As often, this is because C's syntax for variable or prototype declaration
suck..

If D used Limbo and Scala syntax for this <function name>(<parameters>):<return
value>
then there would be no ambiguity:
const memberFunc(param): ReturnType {}
memberFunc(param): const ReturnType {}
const memberFunc(param): const ReturnType {}

Walter has chosen an inferior syntax in the name of programmers familiarity,
this is unlikely to change..

renoX
Mar 05 2008
parent Moritz Warning <moritzwarning _nospam_web.de> writes:
On Wed, 05 Mar 2008 05:40:32 -0500, renoX wrote:


 im Wrote:


[snip]

 
 If D used Limbo and Scala syntax for this <function
 name>(<parameters>):<return value> then there would be no ambiguity:
 const memberFunc(param): ReturnType {} memberFunc(param): const
 ReturnType {} const memberFunc(param): const ReturnType {}
 
 Walter has chosen an inferior syntax in the name of programmers
 familiarity, this is unlikely to change..
 
 renoX


That syntax would be nicer indeed.
We may be able to omit the void return type this way:

"print()" instead of "void print()"

I personally prefer to move the return type into the function header,
but that's another pile of issues.
Mar 07 2008