www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - opMul

reply Denton Cockburn <diboss hotmail.com> writes:
Is there a reason why opMul cannot be called on a constant object?

This restriction is hardcoded (I clearly don't have a choice for my object).
Mar 02 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 02 Mar 2008 20:10:23 +0100, Denton Cockburn <diboss hotmail.com>=
  =

wrote:


 Is there a reason why opMul cannot be called on a constant object?

 This restriction is hardcoded (I clearly don't have a choice for my  =



 object).



That would be due to opMul not being defined as a const function.


import std.stdio;

struct Foo1
{
	int bar;
	=

	Foo1 opMul(int rhs)
	{
		bar *=3D rhs;
		return *this;
	}
}

struct Foo2
{
	int bar;
	=

	Foo2 opMul(int rhs) const // difference here
	{
		bar *=3D rhs;
		return *this;
	}
}

void main()
{
	const Foo1 foo1 =3D Foo1(4);
	Foo1 bar1 =3D foo1 * 3;	// fails

	const Foo2 foo2 =3D Foo2(4);
	Foo2 bar2 =3D foo2 * 3;	// works
}
Mar 02 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Simen Kjaeraas wrote:

 On Sun, 02 Mar 2008 20:10:23 +0100, Denton Cockburn <diboss hotmail.com> 
 wrote:
 

 Is there a reason why opMul cannot be called on a constant object?

 This restriction is hardcoded (I clearly don't have a choice for my 
 object).


 
 
 That would be due to opMul not being defined as a const function.
 
 
 import std.stdio;
 
 struct Foo1
 {
     int bar;
     
     Foo1 opMul(int rhs)
     {
         bar *= rhs;
         return *this;
     }
 }
 
 struct Foo2
 {
     int bar;
     
     Foo2 opMul(int rhs) const // difference here
     {
         bar *= rhs;
         return *this;
     }
 }


I can't keep up here.  Is a trailing 'const' legal D syntax now?

--bb
Mar 02 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 03 Mar 2008 02:01:09 +0100, Bill Baxter  =

<dnewsgroup billbaxter.com> wrote:


 Simen Kjaeraas wrote:

 On Sun, 02 Mar 2008 20:10:23 +0100, Denton Cockburn  =





 <diboss hotmail.com> wrote:


 Is there a reason why opMul cannot be called on a constant object?

 This restriction is hardcoded (I clearly don't have a choice for my =






 =


 object).


   That would be due to opMul not being defined as a const function.
   import std.stdio;
  struct Foo1
 {
     int bar;
         Foo1 opMul(int rhs)
     {
         bar *=3D rhs;
         return *this;
     }
 }
  struct Foo2
 {
     int bar;
         Foo2 opMul(int rhs) const // difference here
     {
         bar *=3D rhs;
         return *this;
     }
 }


 I can't keep up here.  Is a trailing 'const' legal D syntax now?

 --bb


Well, in a way. After becoming sober, I re-read this today and... ouch.

It seems to me that the trailing const says "this function is const,  =

really!" while in fact, it is not. Case in point: above code, which  =

obviously changes this.bar.

Walter (or anyone else who understands const), is this how things are  =

supposed to be?

correct code would be as follows:

import std.stdio;

struct Foo1
{
	int bar;
	=

	Foo1 opMul(int rhs)
	{
		Foo1 tmp;
		tmp.bar =3D bar * rhs;
		return tmp;
	}
}

struct Foo2
{
	int bar;
	=

	const Foo2 opMul(int rhs) // difference here
	{
		Foo2 tmp;
		tmp.bar =3D bar * rhs;
		return tmp;
	}
}

void main()
{
	const Foo1 foo1 =3D Foo1(4);
	Foo1 bar1 =3D foo1 * 3;	// fails

	const Foo2 foo2 =3D Foo2(4);
	Foo2 bar2 =3D foo2 * 3;	// works
}


This correctly fails if this.bar is changed.
Mar 03 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Looks like a compiler bug. The trailing const should work.
Mar 03 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Looks like a compiler bug. The trailing const should work.


No, not a bug.  That seems to work fine.
What doesn't work is doing it *without* const either in front or at the 
end.  And that's correct behavior.

--bb
Mar 03 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 04 Mar 2008 00:31:38 +0100, Bill Baxter  
<dnewsgroup billbaxter.com> wrote:


 Walter Bright wrote:

 Looks like a compiler bug. The trailing const should work.


 No, not a bug.  That seems to work fine.
 What doesn't work is doing it *without* const either in front or at the  
 end.  And that's correct behavior.

 --bb



Bill, take a look at my code. The opMul with trailing const clearly  
changes this.bar, thus it's a bug.
Mar 04 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Simen Kjaeraas wrote:

 On Tue, 04 Mar 2008 00:31:38 +0100, Bill Baxter 
 <dnewsgroup billbaxter.com> wrote:
 

 Walter Bright wrote:

 Looks like a compiler bug. The trailing const should work.


 No, not a bug.  That seems to work fine.
 What doesn't work is doing it *without* const either in front or at 
 the end.  And that's correct behavior.

 --bb


 
 
 Bill, take a look at my code. The opMul with trailing const clearly 
 changes this.bar, thus it's a bug.


Ah, ok.  My mistake.  I don't usually look at the groups with threading 
on because the threads just get too darn deep. And Walter's reply 
contained no context, so I thought he was responding to Denton's part of 
the thread about things compiling.

--bb
Mar 04 2008
prev sibling parent Denton Cockburn <diboss hotmail.com> writes:
On Mon, 03 Mar 2008 14:47:56 -0800, Walter Bright wrote:


 Looks like a compiler bug. The trailing const should work.


So the trailing const will be kept?

Why have it both ways?

(even though there are other things that can be specified in multiple ways)

*joking* Not very pythonic... *joking*
Mar 03 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 03/03/2008, Bill Baxter <dnewsgroup billbaxter.com> wrote:

 I can't keep up here.  Is a trailing 'const' legal D syntax now?


For member functions, yes.
Mar 04 2008
prev sibling parent reply Denton Cockburn <diboss hotmail.com> writes:
On Mon, 03 Mar 2008 01:47:33 +0100, Simen Kjaeraas wrote:


 On Sun, 02 Mar 2008 20:10:23 +0100, Denton Cockburn <diboss hotmail.com>  
 wrote:
 

 Is there a reason why opMul cannot be called on a constant object?

 This restriction is hardcoded (I clearly don't have a choice for my  
 object).


 
 
 That would be due to opMul not being defined as a const function.
 
 
 import std.stdio;
 
 struct Foo1
 {
 	int bar;
 	
 	Foo1 opMul(int rhs)
 	{
 		bar *= rhs;
 		return *this;
 	}
 }
 
 struct Foo2
 {
 	int bar;
 	
 	Foo2 opMul(int rhs) const // difference here
 	{
 		bar *= rhs;
 		return *this;
 	}
 }
 
 void main()
 {
 	const Foo1 foo1 = Foo1(4);
 	Foo1 bar1 = foo1 * 3;	// fails
 
 	const Foo2 foo2 = Foo2(4);
 	Foo2 bar2 = foo2 * 3;	// works
 }


A function does not have to be constant to allow a constant parameter.
It just has to promise not to change the parameter.

I don't understand why opMul would change the parameter, or more
importantly, why it can't be stated that it WONT change the parameter in
any cases.

I think this is related to what Janice spoke about.  The constant changes
that have taken place need to be properly incorporated into the language
and library.  There are a lot of places where constant doesn't work as
would be intuitively expected.
Mar 02 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 03 Mar 2008 04:10:36 +0100, Denton Cockburn <diboss hotmail.com>=
  =

wrote:

 A function does not have to be constant to allow a constant parameter.=



 It just has to promise not to change the parameter.


And that is exactly what const does.


 I don't understand why opMul would change the parameter, or more
 importantly, why it can't be stated that it WONT change the parameter =


in

 any cases.


Given

struct Foo
{
	int bar;
	void doStuff(Foo b)
	{
		bar +=3D b.bar;
	}
}

would you expect

const Foo f,g;
f.doStuff(g);

to work without problems? This is exactly the same, only doStuff is not =
 =

considered special by the compiler.

You might argue that the compiler should enforce opMul, opDiv, etc. to b=
e  =

const, but that does carry a load of other troubles with it.


 I think this is related to what Janice spoke about.  The constant chan=


ges

 that have taken place need to be properly incorporated into the langua=


ge

 and library.  There are a lot of places where constant doesn't work as=



 would be intuitively expected.


This is intuitive to me. (Well, apart from what I mentioned in the  =

response to Bill :p)
Mar 03 2008
parent reply Denton Cockburn <diboss hotmail.com> writes:
On Mon, 03 Mar 2008 15:08:55 +0100, Simen Kjaeraas wrote:


 On Mon, 03 Mar 2008 04:10:36 +0100, Denton Cockburn <diboss hotmail.com>  
 wrote:

 A function does not have to be constant to allow a constant parameter.
 It just has to promise not to change the parameter.


 
 And that is exactly what const does.
 

 I don't understand why opMul would change the parameter, or more
 importantly, why it can't be stated that it WONT change the parameter in
 any cases.


 
 Given
 
 struct Foo
 {
 	int bar;
 	void doStuff(Foo b)
 	{
 		bar += b.bar;
 	}
 }
 
 would you expect
 
 const Foo f,g;
 f.doStuff(g);
 
 to work without problems? This is exactly the same, only doStuff is not  
 considered special by the compiler.
 
 You might argue that the compiler should enforce opMul, opDiv, etc. to be  
 const, but that does carry a load of other troubles with it.
 

 I think this is related to what Janice spoke about.  The constant changes
 that have taken place need to be properly incorporated into the language
 and library.  There are a lot of places where constant doesn't work as
 would be intuitively expected.


 
 This is intuitive to me. (Well, apart from what I mentioned in the  
 response to Bill :p)


You are unfortunately completely missing my point.
In the example you give, you don't want a const parameter, because you
change the object.

I WANT a const parameter, because I have NO INTENTION of changing the
parameter.

so what I want is this:

struct Foo
 {
 	int bar;
 	void doStuff(const Foo b)
 	{
 		bar += b.bar; /* I want an error here */
 	}

	/* now more specifically, I want to do the same as above...but with */
	/* opMul */

	Foo opMul(const Foo b)
	{
		Foo res;
		res.bar = bar * b.bar;

		return res;
	}
 }

See, I make NO changes to the object in that opMul, so my question
is...why is that illegal (intuitively)?
Mar 03 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Denton Cockburn wrote:

 On Mon, 03 Mar 2008 15:08:55 +0100, Simen Kjaeraas wrote:
 

 On Mon, 03 Mar 2008 04:10:36 +0100, Denton Cockburn <diboss hotmail.com>  
 wrote:

 A function does not have to be constant to allow a constant parameter.
 It just has to promise not to change the parameter.


 And that is exactly what const does.


 I don't understand why opMul would change the parameter, or more
 importantly, why it can't be stated that it WONT change the parameter in
 any cases.


 Given

 struct Foo
 {
 	int bar;
 	void doStuff(Foo b)
 	{
 		bar += b.bar;
 	}
 }

 would you expect

 const Foo f,g;
 f.doStuff(g);

 to work without problems? This is exactly the same, only doStuff is not  
 considered special by the compiler.

 You might argue that the compiler should enforce opMul, opDiv, etc. to be  
 const, but that does carry a load of other troubles with it.


 I think this is related to what Janice spoke about.  The constant changes
 that have taken place need to be properly incorporated into the language
 and library.  There are a lot of places where constant doesn't work as
 would be intuitively expected.


 This is intuitive to me. (Well, apart from what I mentioned in the  
 response to Bill :p)


 
 You are unfortunately completely missing my point.
 In the example you give, you don't want a const parameter, because you
 change the object.
 
 I WANT a const parameter, because I have NO INTENTION of changing the
 parameter.
 
 so what I want is this:
 
 struct Foo
  {
  	int bar;
  	void doStuff(const Foo b)
  	{
  		bar += b.bar; /* I want an error here */
  	}


You're not changing b, so you're not going to get an error there.


 	/* now more specifically, I want to do the same as above...but with */
 	/* opMul */
 
 	Foo opMul(const Foo b)
 	{
 		Foo res;
 		res.bar = bar * b.bar;
 
 		return res;
 	}
  }
 
 See, I make NO changes to the object in that opMul, so my question
 is...why is that illegal (intuitively)?


Your question is contradictory.  Above you say you want an error, but 
then ask why is that illegal.  It's not illegal.  It works fine.  Did 
you mean "why is it *legal*?"

If you mean why is it *legal* to use a const parameter like that, the 
answer is because const only says you won't change the parameter. 
Merely accessing a value does not change it.

--bb
Mar 03 2008
parent reply Denton Cockburn <diboss hotmail.com> writes:
On Tue, 04 Mar 2008 05:56:57 +0900, Bill Baxter wrote:


 Denton Cockburn wrote:



 
 so what I want is this:
 
 struct Foo
  {
  	int bar;
  	void doStuff(const Foo b)
  	{
  		bar += b.bar; /* I want an error here */
  	}


 
 You're not changing b, so you're not going to get an error there.


You're right, that was a mistake.

I misphrased my whole query (I misread the compiler error message).
The concern is still there though, here's a sample of code that produces
the message.

struct Foo
{
	int x;
	
	Foo opMul(const Foo b)
	{
		Foo f;
		f.x = x * b.x;
		
		return f;
	}
}

void main()
{
	Foo f;
	Foo y;
	f.x = 6;
	y.x = 7;
	
	const(Foo) t = f;
	Foo p = t * y;
}

produces this error:
test.d(24): function test.Foo.opMul (const(Foo)) does not match parameter types
(Foo)
test.d(24): Error: t.opMul can only be called on a mutable object, not
const(Foo)


So my question SHOULD have been:

Why can't opMul et al be called on a constant object (reference)?

Sorry for the previous confusion.
Mar 03 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Denton Cockburn wrote:

 On Tue, 04 Mar 2008 05:56:57 +0900, Bill Baxter wrote:
 

 Denton Cockburn wrote:


 

 so what I want is this:

 struct Foo
  {
  	int bar;
  	void doStuff(const Foo b)
  	{
  		bar += b.bar; /* I want an error here */
  	}


 You're not changing b, so you're not going to get an error there.


 
 You're right, that was a mistake.
 
 I misphrased my whole query (I misread the compiler error message).
 The concern is still there though, here's a sample of code that produces
 the message.
 
 struct Foo
 {
 	int x;
 	
 	Foo opMul(const Foo b)
 	{
 		Foo f;
 		f.x = x * b.x;
 		
 		return f;
 	}
 }
 
 void main()
 {
 	Foo f;
 	Foo y;
 	f.x = 6;
 	y.x = 7;
 	
 	const(Foo) t = f;
 	Foo p = t * y;
 }
 
 produces this error:
 test.d(24): function test.Foo.opMul (const(Foo)) does not match parameter
types (Foo)
 test.d(24): Error: t.opMul can only be called on a mutable object, not
const(Foo)
 
 
 So my question SHOULD have been:
 
 Why can't opMul et al be called on a constant object (reference)?
 
 Sorry for the previous confusion.


Ok *that's* because saying the parameter is const doesn't mean the 
'this' pointer is const.

To make the hidden 'this' parameter const too you need to use

  const Foo opMul(const Foo b) {...}

That const out front may look like it's modifying the return value, but 
its not.  That would be

  const(Foo) opMul(const Foo b) {...}


--bb
Mar 03 2008
parent reply Denton Cockburn <diboss hotmail.com> writes:
Yep, that did the trick.

IIRC, the const in front means const(this)
Mar 03 2008
next sibling parent Denton Cockburn <diboss hotmail.com> writes:
On Tue, 04 Mar 2008 08:33:00 +0900, Bill Baxter wrote:


 and apparently const at the end means that too, now.
 
    	Foo opMul(const Foo b) const  { // also ok
                ...
          }
 
 
 --bb


I think that was said to be something that's going to be fixed (at some
point).
Mar 03 2008
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Denton Cockburn wrote:

 Yep, that did the trick.
 
 IIRC, the const in front means const(this)
 


and apparently const at the end means that too, now.

        Foo opMul(const Foo [b]) const  { // also ok
               ...
         }


--bb
Mar 05 2008
parent reply "Koroskin Denis" <2korden+dmd gmail.com> writes:
On Thu, 06 Mar 2008 03:04:39 +0300, Bill Baxter  
<dnewsgroup billbaxter.com> wrote:


 Denton Cockburn wrote:

 Yep, that did the trick.

 IIRC, the const in front means const(this)


 and apparently const at the end means that too, now.

         Foo opMul(const Foo [b]) const  { // also ok
                ...
          }


 --bb



This syntax looks less confusing to me. Why keep both?
Mar 06 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 06/03/2008, Koroskin Denis <2korden+dmd gmail.com> wrote:

 This syntax looks less confusing to me. Why keep both?


The syntax /is/ confusing. This is one of those "remaining const
niggles" that is going to keep resurfacing until we come up with
something acceptable to all.

For now, I can tell you that const-at-the-end is allowed (a) for the
benefit of those used to C++ syntax, and (b) for the benefit of those
who just don't like const-at-the-start. Const-at-the-start is allowed
so that you can write stuff like:

    class A
    {
        const
        {
            A opAdd(A a) {...}
            A opSub(A a) {...}
            A opMul(A a) {...}
            A opDiv(A a) {...}
        }
    }

etc. Basically, it saves a lot of typing.

I know I'm repeating myself here, but I still think my previous
suggestion of replacing "const" with "const(this)" and allowing it
only at the front is still a good one. After all, how much extra
typing, proportionately, is

    class A
    {
        const(this)
        {
            A opAdd(A a) {...}
            A opSub(A a) {...}
            A opMul(A a) {...}
            A opDiv(A a) {...}
        }
    }

? And for single functions

    const(this) T f()

is a lot less confusing than

    const T f()

as the former tells me explicitly that "this" is the thing that is
const, wheras the latter makes it look like "T" is const (which it
isn't).

If this is not changed, then years, even decades from now, people will
still be complaining that it's confusing, and while it is true that
you can get used to it, I still think it's better not to confuse in
the first place.
Mar 06 2008
parent reply "Dave" <Dave_member pathlink.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.113.1204800234.2351.digitalmars-d puremagic.com...

 On 06/03/2008, Koroskin Denis <2korden+dmd gmail.com> wrote:

 This syntax looks less confusing to me. Why keep both?


    class A
    {
        const(this)
        {
            A opAdd(A a) {...}
            A opSub(A a) {...}
            A opMul(A a) {...}
            A opDiv(A a) {...}
        }
    }

 ? And for single functions

    const(this) T f()

 is a lot less confusing than

    const T f()

 as the former tells me explicitly that "this" is the thing that is
 const, wheras the latter makes it look like "T" is const (which it
 isn't).


Offhand, that sounds like a great solution to me...

Janice, why has it been "shot down" in the past?

Thanks,

- Dave
Mar 08 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 08/03/2008, Dave <Dave_member pathlink.com> wrote:

  Janice, why has it been "shot down" in the past?

  Thanks,


Simple answer: Walter either doesn't like it or has more important
things to work on.

In fairness, this isn't the /only/ idea which has been suggested, and
I think some people did complain about the extra typing it would need.
Another suggestion was

    T const f()

(the idea being that const applies to whatever is immediately to its
right). I do kinda like that one too, but Walter shot that one down,
primarily I think because it means you can't group multiple functions
together under a single "const" attribute. The "const(this)" idea
doesn't suffer from that disadvantage, but it does mean more typing,
and I think that so long as "the ranks are split", so to speak, then
there's no compelling reason for Walter to move to any particular
choice of solution.

...indeed, I don't think he even acknowledges that there's a problem.
I recall Walter saying that people will just get used to it (that's
from memory, not an exact quote - I apologise if I got that wrong), in
much the same way that we've got used to C++'s const syntax being
inconsistent.

Personally, I like "const(this)", despite the extra typing, because it
opens the door for future expansion (e.g "const(outer)" meaning "this
function will not modify outer").

Dunno if that answers the question or not. Probably not, but I tried.
Mar 08 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 08 Mar 2008 20:00:37 +0100, Janice Caron <caron800 googlemail.com>  
wrote:


 On 08/03/2008, Dave <Dave_member pathlink.com> wrote:

  Janice, why has it been "shot down" in the past?

  Thanks,


 Simple answer: Walter either doesn't like it or has more important
 things to work on.

 In fairness, this isn't the /only/ idea which has been suggested, and
 I think some people did complain about the extra typing it would need.
 Another suggestion was

     T const f()

 (the idea being that const applies to whatever is immediately to its
 right). I do kinda like that one too, but Walter shot that one down,
 primarily I think because it means you can't group multiple functions
 together under a single "const" attribute. The "const(this)" idea
 doesn't suffer from that disadvantage, but it does mean more typing,
 and I think that so long as "the ranks are split", so to speak, then
 there's no compelling reason for Walter to move to any particular
 choice of solution.

 ...indeed, I don't think he even acknowledges that there's a problem.
 I recall Walter saying that people will just get used to it (that's
 from memory, not an exact quote - I apologise if I got that wrong), in
 much the same way that we've got used to C++'s const syntax being
 inconsistent.

 Personally, I like "const(this)", despite the extra typing, because it
 opens the door for future expansion (e.g "const(outer)" meaning "this
 function will not modify outer").

 Dunno if that answers the question or not. Probably not, but I tried.



With trailing const being allowed, I see no problem with T const f(),
and I think it is the most obvious way to write it. For preceding
'const', one logical step would be to allow only const: and const(X):
to be placed in front of functions, and disallow const T f().

-- Simen
Mar 08 2008
parent "Dave" <Dave_member pathlink.com> writes:
"Simen Kjaeraas" <simen.kjaras gmail.com> wrote in message 
news:op.t7pz1mgy1hx7vj spill04.lan...

 On Sat, 08 Mar 2008 20:00:37 +0100, Janice Caron <caron800 googlemail.com> 
 wrote:


 On 08/03/2008, Dave <Dave_member pathlink.com> wrote:

  Janice, why has it been "shot down" in the past?

  Thanks,


 Simple answer: Walter either doesn't like it or has more important
 things to work on.

 In fairness, this isn't the /only/ idea which has been suggested, and
 I think some people did complain about the extra typing it would need.
 Another suggestion was

     T const f()

 (the idea being that const applies to whatever is immediately to its
 right). I do kinda like that one too, but Walter shot that one down,
 primarily I think because it means you can't group multiple functions
 together under a single "const" attribute. The "const(this)" idea
 doesn't suffer from that disadvantage, but it does mean more typing,
 and I think that so long as "the ranks are split", so to speak, then
 there's no compelling reason for Walter to move to any particular
 choice of solution.

 ...indeed, I don't think he even acknowledges that there's a problem.
 I recall Walter saying that people will just get used to it (that's
 from memory, not an exact quote - I apologise if I got that wrong), in
 much the same way that we've got used to C++'s const syntax being
 inconsistent.

 Personally, I like "const(this)", despite the extra typing, because it
 opens the door for future expansion (e.g "const(outer)" meaning "this
 function will not modify outer").

 Dunno if that answers the question or not. Probably not, but I tried.



 With trailing const being allowed, I see no problem with T const f(),
 and I think it is the most obvious way to write it. For preceding
 'const', one logical step would be to allow only const: and const(X):
 to be placed in front of functions, and disallow const T f().

 -- Simen


Actually, now that I see that:

const T function_without_this(){}

is not allowed, I think the current idiom is acceptable because it's 
consistent.
Mar 08 2008
prev sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.134.1205002850.2351.digitalmars-d puremagic.com...

 On 08/03/2008, Dave <Dave_member pathlink.com> wrote:

  Janice, why has it been "shot down" in the past?

  Thanks,


 Simple answer: Walter either doesn't like it or has more important
 things to work on.

 In fairness, this isn't the /only/ idea which has been suggested, and
 I think some people did complain about the extra typing it would need.
 Another suggestion was

    T const f()


I like that one also.


 (the idea being that const applies to whatever is immediately to its
 right). I do kinda like that one too, but Walter shot that one down,
 primarily I think because it means you can't group multiple functions
 together under a single "const" attribute. The "const(this)" idea
 doesn't suffer from that disadvantage, but it does mean more typing,
 and I think that so long as "the ranks are split", so to speak, then
 there's no compelling reason for Walter to move to any particular
 choice of solution.

 ...indeed, I don't think he even acknowledges that there's a problem.
 I recall Walter saying that people will just get used to it (that's
 from memory, not an exact quote - I apologise if I got that wrong), in
 much the same way that we've got used to C++'s const syntax being
 inconsistent.

 Personally, I like "const(this)", despite the extra typing, because it
 opens the door for future expansion (e.g "const(outer)" meaning "this
 function will not modify outer").

 Dunno if that answers the question or not. Probably not, but I tried.


Yes, that answers it - thanks.

I think either const(this) or T const f() are prefereable to trailing const.
Mar 08 2008
parent "Dave" <Dave_member pathlink.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:fqv8qj$1ol3$1 digitalmars.com...

 I think either const(this) or T const f() are prefereable to trailing 
 const.


OTOH, "T f() const" is not only familiar to C++ programmers but it is now 
consistent with another function modifier, 'nothrow'. And since it would 
then allow for:

const T function_without_this(){}

it would be yet more consistent with how const is used elsewhere with types.

Walter, is this why you added trailing const?

- Dave
Mar 08 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
As an aside, Walter has now given us the syntax

    this(this) { ... }

for post-processing of structs after a bitwise copy. That's completely
unrelated, of course, but it struck me as interesting that there is
now a precedent for "this in brackets", even though in a different
context.
Mar 08 2008
prev sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 06 Mar 2008 11:29:33 +0100, Koroskin Denis <2korden+dmd gmail.com>  
wrote:


 On Thu, 06 Mar 2008 03:04:39 +0300, Bill Baxter  
 <dnewsgroup billbaxter.com> wrote:


 Denton Cockburn wrote:

 Yep, that did the trick.

 IIRC, the const in front means const(this)


 and apparently const at the end means that too, now.

         Foo opMul(const Foo [b]) const  { // also ok
                ...
          }


 --bb



 This syntax looks less confusing to me. Why keep both?



I agree. With const foo x; meaning x is const, const foo y(){} meaning y  
is const... wait, this actually does seem to make sense when you look at  
it like that.

Better way to think of it: const foo x; is the same as const(foo) x;.  
Thus, const foo y(){}; should also mean const(foo) y(){};.

Going with how D const should apply to whatever is directly after it, foo  
const y(){}; appears to me the most logical way of writing it. Trailing  
const is also acceptable to me, seeing as there's nothing else that const  
could refer to.

-- Simen
Mar 06 2008
parent "Janice Caron" <caron800 googlemail.com> writes:
On 06/03/2008, Simen Kjaeraas <simen.kjaras gmail.com> wrote:

  const foo x; is the same as const(foo) x;.
  Thus, const foo y(){}; should also mean const(foo) y(){};.


And of course, it doesn't. (Obviously, you knew that).

But that's the problem, I agree.
Mar 06 2008