www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Suggestion: object const'ness

reply ChristopheBourez <ChristopheBourez_member pathlink.com> writes:
It should be interesting to have a const'ness ala C++, I mean, the ability to
declare methods that do not modify the state of objects.

class X 
{ 
public:
void ModifyState?();
void DontModifyState?() const;
};

Any comments?

Christophe
May 19 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
ChristopheBourez wrote:

 It should be interesting to have a const'ness ala C++, I mean, the ability to
 declare methods that do not modify the state of objects.
 
 class X 
 { 
 public:
 void ModifyState?();
 void DontModifyState?() const;
 };
 
 Any comments?
 
 Christophe
 
 


I think this has been discussed to death. (the const thing in general)
Summary: probably not gonna happen.
May 19 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Hasan Aljudy wrote:


 ChristopheBourez wrote:

 It should be interesting to have a const'ness ala C++, I mean, the
 ability to declare methods that do not modify the state of objects.
 
 class X
 { 
 public:
 void ModifyState?();
 void DontModifyState?() const;
 };
 
 Any comments?
 
 Christophe
 
 


 
 I think this has been discussed to death. (the const thing in general)
 Summary: probably not gonna happen.


Hmm, no, the summary is that it will probably happen when Walter finds a
solution he is satisfied with. There was some talk on one solution just a
few days ago that he found he very interesting, at least for debug builds.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
May 19 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Hasan Aljudy wrote:

 ChristopheBourez wrote:

 It should be interesting to have a const'ness ala C++, I mean, the 
 ability to
 declare methods that do not modify the state of objects.

 class X { public:
 void ModifyState?();
 void DontModifyState?() const;
 };

 Any comments?

 Christophe


 
 I think this has been discussed to death. (the const thing in general)
 Summary: probably not gonna happen.


Walter mentioned recently in the C++ forum that D would eventually get 
some form of const. However, it surely won't be à la C++.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 20 2006
prev sibling next sibling parent reply Tom <ihate spam.com> writes:
One of the flaws of the language IMHO. Also in/out/inout is flawed and 
seems merely informative instead of being strict in allowing/disallowing 
parameter modification. I'm on the side of const-like solution and 
*TRUE* in/out/inout param attributes. When I first read about D and all 
these promising features I was really amazed till I try some of them 
(like in/out/etc). I felt disappointed though I still love the language 
and it's a shame this little stuff doesn't work as one expect.

Some of the allegations against const was that it could easily be 
circumvented. I wonder which feature couldn't be circumvented if inline 
asm is permitted. Anyway, I hope all this to be fixed before 1.0.

--
Tom;

ChristopheBourez escribió:

 It should be interesting to have a const'ness ala C++, I mean, the ability to
 declare methods that do not modify the state of objects.
 
 class X 
 { 
 public:
 void ModifyState?();
 void DontModifyState?() const;
 };
 
 Any comments?
 
 Christophe
May 19 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Tom" <ihate spam.com> wrote in message 
news:e4ll86$q0e$1 digitaldaemon.com...


 One of the flaws of the language IMHO. Also in/out/inout is flawed and 
 seems merely informative instead of being strict in allowing/disallowing 
 parameter modification. I'm on the side of const-like solution and *TRUE* 
 in/out/inout param attributes. When I first read about D and all these 
 promising features I was really amazed till I try some of them (like 
 in/out/etc). I felt disappointed though I still love the language and it's 
 a shame this little stuff doesn't work as one expect.


Just curious; what do you mean by "true" in/out/inout?  Do you mean that 
"in" parameters should not be modifiable (kind of like const)?  If so, what 
about out/inout?
May 20 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sat, 20 May 2006 20:44:52 -0400, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:


 "Tom" <ihate spam.com> wrote in message
 news:e4ll86$q0e$1 digitaldaemon.com...


 One of the flaws of the language IMHO. Also in/out/inout is flawed and
 seems merely informative instead of being strict in allowing/disallowing
 parameter modification. I'm on the side of const-like solution and  
 *TRUE*
 in/out/inout param attributes. When I first read about D and all these
 promising features I was really amazed till I try some of them (like
 in/out/etc). I felt disappointed though I still love the language and  
 it's
 a shame this little stuff doesn't work as one expect.


 Just curious; what do you mean by "true" in/out/inout?  Do you mean that
 "in" parameters should not be modifiable (kind of like const)?


I believe that's exactly what he means. I proposed the same thing in one  
of the many past const debates. It just makes sense to me that if a  
parameter is passed as 'in' you will not be modifying it, if you were  
modifying it you'd clearly be passing it as 'inout'.

'in' is the default parameter type, so this would mean that by default  
parameters are not modifyable. Which in turn means you have to actually  
think about and indicate the parameters you are going to modify.

There remains a problem that passing say an object reference by 'in' only  
really says "I will not modify this object reference", and gives no  
guarantee about the data to which it refers (same goes for array  
references, or any kind of reference). So there is actually several layers  
of immutability to handle, somehow.

I'm very much in favour of some sort of "const" solution which involves  
'in', 'out', etc.


 If so, what about out/inout?


'out'   - initialized to type.init and expects to be modified (not const)
'inout' - expects to be modified (not const)

Regan
May 20 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Regan Heath wrote:

 On Sat, 20 May 2006 20:44:52 -0400, Jarrett Billingsley  
 <kb3ctd2 yahoo.com> wrote:
 

 "Tom" <ihate spam.com> wrote in message
 news:e4ll86$q0e$1 digitaldaemon.com...


 One of the flaws of the language IMHO. Also in/out/inout is flawed and
 seems merely informative instead of being strict in allowing/disallowing
 parameter modification. I'm on the side of const-like solution and  
 *TRUE*
 in/out/inout param attributes. When I first read about D and all these
 promising features I was really amazed till I try some of them (like
 in/out/etc). I felt disappointed though I still love the language 
 and  it's
 a shame this little stuff doesn't work as one expect.



 Just curious; what do you mean by "true" in/out/inout?  Do you mean that
 "in" parameters should not be modifiable (kind of like const)?


 
 
 I believe that's exactly what he means. I proposed the same thing in 
 one  of the many past const debates. It just makes sense to me that if 
 a  parameter is passed as 'in' you will not be modifying it, if you 
 were  modifying it you'd clearly be passing it as 'inout'.
 
 'in' is the default parameter type, so this would mean that by default  
 parameters are not modifyable. Which in turn means you have to actually  
 think about and indicate the parameters you are going to modify.
 
 There remains a problem that passing say an object reference by 'in' 
 only  really says "I will not modify this object reference", and gives 
 no  guarantee about the data to which it refers (same goes for array  
 references, or any kind of reference). So there is actually several 
 layers  of immutability to handle, somehow.
 
 I'm very much in favour of some sort of "const" solution which involves  
 'in', 'out', etc.
 

 If so, what about out/inout?


 
 
 'out'   - initialized to type.init and expects to be modified (not const)
 'inout' - expects to be modified (not const)
 
 Regan


huh? if you pass an object reference as in you shouldn't be able to 
manipulate the object?!!
In what sense is that a "true" in?

That's just an arbitrary restriction.
May 20 2006
next sibling parent reply Tom <ihate spam.com> writes:
Hasan Aljudy escribió:

 Regan Heath wrote:

 On Sat, 20 May 2006 20:44:52 -0400, Jarrett Billingsley  
 <kb3ctd2 yahoo.com> wrote:


 "Tom" <ihate spam.com> wrote in message
 news:e4ll86$q0e$1 digitaldaemon.com...


 One of the flaws of the language IMHO. Also in/out/inout is flawed and
 seems merely informative instead of being strict in 
 allowing/disallowing
 parameter modification. I'm on the side of const-like solution and  
 *TRUE*
 in/out/inout param attributes. When I first read about D and all these
 promising features I was really amazed till I try some of them (like
 in/out/etc). I felt disappointed though I still love the language 
 and  it's
 a shame this little stuff doesn't work as one expect.



 Just curious; what do you mean by "true" in/out/inout?  Do you mean that
 "in" parameters should not be modifiable (kind of like const)?



 I believe that's exactly what he means. I proposed the same thing in 
 one  of the many past const debates. It just makes sense to me that if 
 a  parameter is passed as 'in' you will not be modifying it, if you 
 were  modifying it you'd clearly be passing it as 'inout'.

 'in' is the default parameter type, so this would mean that by 
 default  parameters are not modifyable. Which in turn means you have 
 to actually  think about and indicate the parameters you are going to 
 modify.

 There remains a problem that passing say an object reference by 'in' 
 only  really says "I will not modify this object reference", and gives 
 no  guarantee about the data to which it refers (same goes for array  
 references, or any kind of reference). So there is actually several 
 layers  of immutability to handle, somehow.

 I'm very much in favour of some sort of "const" solution which 
 involves  'in', 'out', etc.


 If so, what about out/inout?



 'out'   - initialized to type.init and expects to be modified (not const)
 'inout' - expects to be modified (not const)

 Regan


 
 huh? if you pass an object reference as in you shouldn't be able to 
 manipulate the object?!!
 In what sense is that a "true" in?
 
 That's just an arbitrary restriction.


It isn't. That's how is expected to work for any reasonable use.

If you see a signature like this:

void doSomething(in SomeObj obj1, inout SomeObj obj2);

You'll instantly expect that function "doSomething" doesn't modify obj1 
   and do posibly modify obj2 (the object and not it's reference). Why 
would you want (in the most of the cases) to make "in" the reference itself?

Currently D 'in Obj p' "behaves as" the rarely-used 'Obj *const p' and 
not as the widely and common 'const Obj *p' of C++ ("behave as" because 
I use pointers instead of references to illustrate the underlying 
behavior and C++ references are always const).

Const is another level of protection against unintended behavior (i.e. 
bugs). In C++, const *can* be circumvented but one has to be horribly 
explicit to do that. No way you would unintentionally do that.

--
Tom;
May 20 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
.

 If you see a signature like this:

 void doSomething(in SomeObj obj1, inout SomeObj obj2);

 You'll instantly expect that function "doSomething" doesn't modify obj1


But it doesn't modify 'obj1'. Remembering that 'obj1' is the reference to  
the object and not the object itself.


    and do posibly modify obj2 (the object and not it's reference). Why  
 would you want (in the most of the cases) to make "in" the reference  
 itself?


Don't know. Simplier I guess.


 Currently D 'in Obj p' "behaves as" the rarely-used 'Obj *const p' and  
 not as the widely and common 'const Obj *p' of C++ ("behave as" because  
 I use pointers instead of references to illustrate the underlying  
 behavior and C++ references are always const).

 Const is another level of protection against unintended behavior (i.e.  
 bugs). In C++, const *can* be circumvented but one has to be horribly  
 explicit to do that. No way you would unintentionally do that.


So everyone repeat after me ... D is not C++, D is not C++, D is not C++,  
...  ;-)

-- 
Derek Parnell
Melbourne, Australia
May 21 2006
parent reply Tom <ihate spam.com> writes:
Derek Parnell escribió:

 .

 If you see a signature like this:

 void doSomething(in SomeObj obj1, inout SomeObj obj2);

 You'll instantly expect that function "doSomething" doesn't modify obj1


 
 But it doesn't modify 'obj1'. Remembering that 'obj1' is the reference 
 to the object and not the object itself.


If you read just below you'll notice I was referring to obj1 as the 
object and not as it's reference.
|
V


    and do possibly modify obj2 (the object and not it's reference). Why 
 would you want (in the most of the cases) to make "in" the reference 
 itself?


 
 Don't know. Simplier I guess.


Exactly, no one knows why, it's simply useless. At present, in D is 
perfectly pointless (merely informative) to use 'in' with reference 
parameters, at least for the 99% of the cases.


 Currently D 'in Obj p' "behaves as" the rarely-used 'Obj *const p' and 
 not as the widely and common 'const Obj *p' of C++ ("behave as" 
 because I use pointers instead of references to illustrate the 
 underlying behavior and C++ references are always const).

 Const is another level of protection against unintended behavior (i.e. 
 bugs). In C++, const *can* be circumvented but one has to be horribly 
 explicit to do that. No way you would unintentionally do that.


 
 So everyone repeat after me ... D is not C++, D is not C++, D is not 
 C++, ...  ;-)


I know that Derek. Just that *many* of the users that come to D, don't 
know if you realize it, comes from the C++ world. It's understandable, 
we like the features of C++ but hate the syntax (and other stuff) and we 
see D as a better C++. It's perfectly natural to try to achieve the same 
things in D that we've achieved in C++. Don't be afraid, I'd hate to see 
D become another C++ (and that's not gonna happen for sure).

For C++ users, 'in' parameters (for references) are 'const Obj &o', 
inout/out parameters are 'Obj &o'. When you see that on a signature you 
can be "sure" (there's always some reasonable trust in the middle) the 
function will not modify the object (you don't care about the object 
reference). In D in/out/inout are just a disappointment (for C++ users). 
I've dreamed to see that keywords used with the same meaning as what 
I've mentioned above.


 --Derek Parnell
 Melbourne, Australia
May 21 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Tom wrote:

 Derek Parnell escribió:
 

 .


 If you see a signature like this:

 void doSomething(in SomeObj obj1, inout SomeObj obj2);

 You'll instantly expect that function "doSomething" doesn't modify obj1



 But it doesn't modify 'obj1'. Remembering that 'obj1' is the reference 
 to the object and not the object itself.


 
 
 If you read just below you'll notice I was referring to obj1 as the 
 object and not as it's reference.
 |
 V
 

    and do possibly modify obj2 (the object and not it's reference). 
 Why would you want (in the most of the cases) to make "in" the 
 reference itself?



 Don't know. Simplier I guess.


 
 
 Exactly, no one knows why, it's simply useless. At present, in D is 
 perfectly pointless (merely informative) to use 'in' with reference 
 parameters, at least for the 99% of the cases.
 

 Currently D 'in Obj p' "behaves as" the rarely-used 'Obj *const p' 
 and not as the widely and common 'const Obj *p' of C++ ("behave as" 
 because I use pointers instead of references to illustrate the 
 underlying behavior and C++ references are always const).

 Const is another level of protection against unintended behavior 
 (i.e. bugs). In C++, const *can* be circumvented but one has to be 
 horribly explicit to do that. No way you would unintentionally do that.



 So everyone repeat after me ... D is not C++, D is not C++, D is not 
 C++, ...  ;-)


 
 
 I know that Derek. Just that *many* of the users that come to D, don't 
 know if you realize it, comes from the C++ world. It's understandable, 
 we like the features of C++ but hate the syntax (and other stuff) and we 
 see D as a better C++. It's perfectly natural to try to achieve the same 
 things in D that we've achieved in C++. Don't be afraid, I'd hate to see 
 D become another C++ (and that's not gonna happen for sure).
 
 For C++ users, 'in' parameters (for references) are 'const Obj &o', 
 inout/out parameters are 'Obj &o'. When you see that on a signature you 
 can be "sure" (there's always some reasonable trust in the middle) the 
 function will not modify the object (you don't care about the object 
 reference). In D in/out/inout are just a disappointment (for C++ users). 
 I've dreamed to see that keywords used with the same meaning as what 
 I've mentioned above.
 

 --Derek Parnell
 Melbourne, Australia




"D is not C++" implies the following:
Don't try to achieve things the same way as in C++!!

It's not just the syntax that's different, it's a lot of features too.
For example: objects are always by reference, never by value.
This make for a huge difference; it results in a completely different 
behaviour in many situations. (for the better).

I would advice you to try Java for a while, maybe it can help you get 
rid of useless C++ idioms. :)
May 21 2006
next sibling parent reply ChristopheBourez <ChristopheBourez_member pathlink.com> writes:
In article <e4q2jv$2pil$1 digitaldaemon.com>, Hasan Aljudy says...

[...snip...]

We are not advocating in favour of C++. There are some idioms independent of the
language. OOP is one, generics/template is another, RAII and so on (all present
in C++). The only thing we are trying to explain is that there is also the
const'ness concept. And it should be good to think about it. And nobody says
that this concept must be implemented the same way as it was in C++.



 
 I know that Derek. Just that *many* of the users that come to D, don't 
 know if you realize it, comes from the C++ world. It's understandable, 
 we like the features of C++ but hate the syntax (and other stuff) and we 
 see D as a better C++. It's perfectly natural to try to achieve the same 
 things in D that we've achieved in C++. Don't be afraid, I'd hate to see 
 D become another C++ (and that's not gonna happen for sure).




Thank you, Tom, it is well summarized.


 
 For C++ users, 'in' parameters (for references) are 'const Obj &o', 
 inout/out parameters are 'Obj &o'. When you see that on a signature you 
 can be "sure" (there's always some reasonable trust in the middle) the 
 function will not modify the object (you don't care about the object 
 reference). In D in/out/inout are just a disappointment (for C++ users). 
 I've dreamed to see that keywords used with the same meaning as what 
 I've mentioned above.
 




[...snip...]


"D is not C++" implies the following:
Don't try to achieve things the same way as in C++!!

It's not just the syntax that's different, it's a lot of features too.
For example: objects are always by reference, never by value.
This make for a huge difference; it results in a completely different 
behaviour in many situations. (for the better).


A good C++ programmers already used "objects by reference ala Java": it is a
little bit different and sometimes(often?) called boost::smart_ptr<T>. Don't
think that C++ programmers are writing always bugged code.


I would advice you to try Java for a while, maybe it can help you get 
rid of useless C++ idioms. :)
May 21 2006
parent Tom <ihate spam.com> writes:
ChristopheBourez escribió:

 In article <e4q2jv$2pil$1 digitaldaemon.com>, Hasan Aljudy says...


[...snip...]


 We are not advocating in favour of C++. There are some idioms independent of
the
 language. OOP is one, generics/template is another, RAII and so on (all present
 in C++). The only thing we are trying to explain is that there is also the
 const'ness concept. And it should be good to think about it. And nobody says
 that this concept must be implemented the same way as it was in C++.


I'll always fight for D to implement in some way these features. If I 
can't make it, it's not the end of the world, we just accept it and 
period. Despite all these details I'd love to see implemented/improved, 
D is a great language yet!


 I know that Derek. Just that *many* of the users that come to D, don't 
 know if you realize it, comes from the C++ world. It's understandable, 
 we like the features of C++ but hate the syntax (and other stuff) and we 
 see D as a better C++. It's perfectly natural to try to achieve the same 
 things in D that we've achieved in C++. Don't be afraid, I'd hate to see 
 D become another C++ (and that's not gonna happen for sure).




 
 Thank you, Tom, it is well summarized.


You're welcome.

[...snip...]


 It's not just the syntax that's different, it's a lot of features too.
 For example: objects are always by reference, never by value.
 This make for a huge difference; it results in a completely different 
 behaviour in many situations. (for the better).


 
 A good C++ programmers already used "objects by reference ala Java": it is a
 little bit different and sometimes(often?) called boost::smart_ptr<T>. Don't
 think that C++ programmers are writing always bugged code.


That's right! After all, DMD is a C++ product, isn't it? :)
May 21 2006
prev sibling parent reply Tom <ihate spam.com> writes:
Hasan Aljudy escribió:

 Tom wrote:

 Derek Parnell escribió:


 .


 If you see a signature like this:

 void doSomething(in SomeObj obj1, inout SomeObj obj2);

 You'll instantly expect that function "doSomething" doesn't modify obj1



 But it doesn't modify 'obj1'. Remembering that 'obj1' is the 
 reference to the object and not the object itself.



 If you read just below you'll notice I was referring to obj1 as the 
 object and not as it's reference.
 |
 V


    and do possibly modify obj2 (the object and not it's reference). 
 Why would you want (in the most of the cases) to make "in" the 
 reference itself?



 Don't know. Simplier I guess.



 Exactly, no one knows why, it's simply useless. At present, in D is 
 perfectly pointless (merely informative) to use 'in' with reference 
 parameters, at least for the 99% of the cases.


 Currently D 'in Obj p' "behaves as" the rarely-used 'Obj *const p' 
 and not as the widely and common 'const Obj *p' of C++ ("behave as" 
 because I use pointers instead of references to illustrate the 
 underlying behavior and C++ references are always const).

 Const is another level of protection against unintended behavior 
 (i.e. bugs). In C++, const *can* be circumvented but one has to be 
 horribly explicit to do that. No way you would unintentionally do that.



 So everyone repeat after me ... D is not C++, D is not C++, D is not 
 C++, ...  ;-)



 I know that Derek. Just that *many* of the users that come to D, don't 
 know if you realize it, comes from the C++ world. It's understandable, 
 we like the features of C++ but hate the syntax (and other stuff) and 
 we see D as a better C++. It's perfectly natural to try to achieve the 
 same things in D that we've achieved in C++. Don't be afraid, I'd hate 
 to see D become another C++ (and that's not gonna happen for sure).

 For C++ users, 'in' parameters (for references) are 'const Obj &o', 
 inout/out parameters are 'Obj &o'. When you see that on a signature 
 you can be "sure" (there's always some reasonable trust in the middle) 
 the function will not modify the object (you don't care about the 
 object reference). In D in/out/inout are just a disappointment (for 
 C++ users). I've dreamed to see that keywords used with the same 
 meaning as what I've mentioned above.


 --Derek Parnell
 Melbourne, Australia




 
 "D is not C++" implies the following:
 Don't try to achieve things the same way as in C++!!
 
 It's not just the syntax that's different, it's a lot of features too.
 For example: objects are always by reference, never by value.
 This make for a huge difference; it results in a completely different 
 behaviour in many situations. (for the better).
 
 I would advice you to try Java for a while, maybe it can help you get 
 rid of useless C++ idioms. :)


I work with JAVA as well. I like it as a language but I hate its VM, its 
gigantic JDK and its slowness. Native compiled Java would be great if 
you ask. Anyway I think I get your point.
Just a few questions, is in/out/inout useful for you in any way? 
Wouldn't it be more honest to remove in/out/inout and replace it for 
some kind of 'byref' attribute?

Regards,
--
Tom;
May 21 2006
next sibling parent "Derek Parnell" <derek psych.ward> writes:
On Mon, 22 May 2006 07:44:55 +1000, Tom <ihate spam.com> wrote:



 Just a few questions, is in/out/inout useful for you in any way?  
 Wouldn't it be more honest to remove in/out/inout and replace it for  
 some kind of 'byref' attribute?


No. I don't come from either C++ or Java background. The 'in' no longer  
scares me now that I can think in D too. In those situations that are  
critical that an object/array passed as a parameter is not modified, I  
pass a copy of that object/array. In other words, as I know that the  
compiler is not helpful in this situation, I take responsiblity for the  
application.

Likewise, if my class returns a reference to something that only the class  
is allowed to modify, I return a copy of that data instead. I know that  
DMD will not help me so I take control.

Yes I know that this is more work on my part and more runtime overheads,  
but it works. So in that sense, DMD is not as sophisticated and helpful as  
C++, but it offers other benefits that outweight this blemish.

-- 
Derek Parnell
Melbourne, Australia
May 21 2006
prev sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Tom wrote:

 Hasan Aljudy escribió:
 

 Tom wrote:


 Derek Parnell escribió:


 .


 If you see a signature like this:

 void doSomething(in SomeObj obj1, inout SomeObj obj2);

 You'll instantly expect that function "doSomething" doesn't modify 
 obj1




 But it doesn't modify 'obj1'. Remembering that 'obj1' is the 
 reference to the object and not the object itself.




 If you read just below you'll notice I was referring to obj1 as the 
 object and not as it's reference.
 |
 V


    and do possibly modify obj2 (the object and not it's reference). 
 Why would you want (in the most of the cases) to make "in" the 
 reference itself?




 Don't know. Simplier I guess.




 Exactly, no one knows why, it's simply useless. At present, in D is 
 perfectly pointless (merely informative) to use 'in' with reference 
 parameters, at least for the 99% of the cases.


 Currently D 'in Obj p' "behaves as" the rarely-used 'Obj *const p' 
 and not as the widely and common 'const Obj *p' of C++ ("behave as" 
 because I use pointers instead of references to illustrate the 
 underlying behavior and C++ references are always const).

 Const is another level of protection against unintended behavior 
 (i.e. bugs). In C++, const *can* be circumvented but one has to be 
 horribly explicit to do that. No way you would unintentionally do 
 that.




 So everyone repeat after me ... D is not C++, D is not C++, D is not 
 C++, ...  ;-)




 I know that Derek. Just that *many* of the users that come to D, 
 don't know if you realize it, comes from the C++ world. It's 
 understandable, we like the features of C++ but hate the syntax (and 
 other stuff) and we see D as a better C++. It's perfectly natural to 
 try to achieve the same things in D that we've achieved in C++. Don't 
 be afraid, I'd hate to see D become another C++ (and that's not gonna 
 happen for sure).

 For C++ users, 'in' parameters (for references) are 'const Obj &o', 
 inout/out parameters are 'Obj &o'. When you see that on a signature 
 you can be "sure" (there's always some reasonable trust in the 
 middle) the function will not modify the object (you don't care about 
 the object reference). In D in/out/inout are just a disappointment 
 (for C++ users). I've dreamed to see that keywords used with the same 
 meaning as what I've mentioned above.


 --Derek Parnell
 Melbourne, Australia





 "D is not C++" implies the following:
 Don't try to achieve things the same way as in C++!!

 It's not just the syntax that's different, it's a lot of features too.
 For example: objects are always by reference, never by value.
 This make for a huge difference; it results in a completely different 
 behaviour in many situations. (for the better).

 I would advice you to try Java for a while, maybe it can help you get 
 rid of useless C++ idioms. :)


 
 
 I work with JAVA as well. I like it as a language but I hate its VM, its 
 gigantic JDK and its slowness. Native compiled Java would be great if 
 you ask. Anyway I think I get your point.
 Just a few questions, is in/out/inout useful for you in any way? 
 Wouldn't it be more honest to remove in/out/inout and replace it for 
 some kind of 'byref' attribute?
 
 Regards,
 -- 
 Tom;


This is just my opinion .. I don't think it's a big deal though, but 
since you asked, here's what I think:
I think a "ref" or "byref" keyword would be more meaningful than "inout".
"in" is the default and shouldn't need a keyword anyway.
"out" is somewhat similar to inout (see my post/question in the learning 
NG); it offers no special functionality, and I think it's rarely ever 
used. so it's really not needed.

PS: "in" and "out" would still be keywords; they're used in function 
contracts.
May 21 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 21 May 2006 17:58:57 -0600, Hasan Aljudy <hasan.aljudy gmail.com>  
wrote:

 This is just my opinion .. I don't think it's a big deal though, but  
 since you asked, here's what I think:
 I think a "ref" or "byref" keyword would be more meaningful than "inout".


I disagree. "byref" is _less_ meaningful (read on for my reasoning).


 "in" is the default and shouldn't need a keyword anyway.


Agreed. It's probably only there for the Derek's of this world :)
Each to their own I say.


 "out" is somewhat similar to inout (see my post/question in the learning  
 NG); it offers no special functionality, and I think it's rarely ever  
 used. so it's really not needed.


I use "out" in cases like:

void loadX(out int a, out int b, out int c);

where X can be anything you like i.e. UserDefaults or ServerSettings or  
whatever. Where the types need not be 'int', where they would have more  
meaningful names than a, b, and c. Basically in any situation where you  
want to return more than 1 "result" from the function.

(yes, there are other ways to do this sort of thing i.e. returning a  
composite data type struct/class etc)

The fact that "out" initialises the variables to their init values is  
important, just like D's other instances of default initialisation for  
variables. The other reason you would use "out" and not "inout" is that  
"inout" implies "input" as well as "output" and that's clearly not the  
case here. So saying "inout", or not saying anything (byref) is wrong,  
confusing or _less_ meaningful.

In short, "byref" says "this is being passed by reference" whereas "out"  
says "this variable will recieve output from this function", likewise  
"inout" says "this variable contains input and will/may receive output  
 from this function". In short, "out" and "inout" hold more meaning than  
"byref" would.

In actual fact, "out" and "inout" don't actually state the variable will  
be passed by reference, that's just how it happens to be implemented.  
There may in fact be no other way to do it, but that's not the point. The  
point is that "out" and "inout" do not mean "this is being passed by  
reference", they never have (IMO, of course).


 PS: "in" and "out" would still be keywords; they're used in function  
 contracts.


To my mind "out" and "inout" are solely function contracts. They just  
happen to cause pass by reference (because that's how they achieve their  
goal).

I don't want to re-start the old "byref" discussion, but, I still cannot  
see a need for it(byref). If you want to pass a struct, or other value  
type, as input, by reference, you just use a pointer, eg.

struct A { int abc; }
void foo(in A* p) {
   //note D automatically de-references the pointer for you (in most cases)
   p.abc = 5;
}

Until we get some sort of const system, the 'in' parameter, the pointer  
'p', is all that is 'protected' from modification, it's contents are open  
to modification.

Now, you _could_ pass it by value, that would protect it's contents, but  
what about the contents of it's contents, for example:

struct A { char *str; }
void foo(A a) { a.str[0] = 'a'; }

any reference contained in a struct is itself protected, but not so the  
data to which it refers. Any const system would ideally therefore need to  
handle several layers of protection, perhaps my preventing the use of  
reference types as an lvalue?


All in all, I guess all I'm trying to say is that I like "out" and "inout"  
I think they perform a valid and valuable task, in fact they're a big step  
up from the days of using a pointer or passing by reference because they  
add _more_ meaning, they actually tell you what the function programmer  
intended to do with the parameter.

I would like to see some sort of const guarantee and I think "in" should  
play a part, I think by default parameters should be passed as "in" (as  
they are) and should be protected/const/read-only by default.

Regan
May 21 2006
parent Derek Parnell <derek psych.ward> writes:
On Mon, 22 May 2006 12:50:47 +1200, Regan Heath wrote:

...


 All in all, I guess all I'm trying to say is that I like "out" and "inout"  
 I think they perform a valid and valuable task, in fact they're a big step  
 up from the days of using a pointer or passing by reference because they  
 add _more_ meaning, they actually tell you what the function programmer  
 intended to do with the parameter.
 
 I would like to see some sort of const guarantee and I think "in" should  
 play a part, I think by default parameters should be passed as "in" (as  
 they are) and should be protected/const/read-only by default.


Yeah ... like Regan said. 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
22/05/2006 11:25:43 AM
May 21 2006
prev sibling parent Tom <ihate spam.com> writes:
Hasan Aljudy escribió:

 Tom wrote:

 Hasan Aljudy escribió:


 Tom wrote:


 Derek Parnell escribió:


 .


 If you see a signature like this:

 void doSomething(in SomeObj obj1, inout SomeObj obj2);

 You'll instantly expect that function "doSomething" doesn't modify 
 obj1




 But it doesn't modify 'obj1'. Remembering that 'obj1' is the 
 reference to the object and not the object itself.




 If you read just below you'll notice I was referring to obj1 as the 
 object and not as it's reference.
 |
 V


    and do possibly modify obj2 (the object and not it's 
 reference). Why would you want (in the most of the cases) to make 
 "in" the reference itself?




 Don't know. Simplier I guess.




 Exactly, no one knows why, it's simply useless. At present, in D is 
 perfectly pointless (merely informative) to use 'in' with reference 
 parameters, at least for the 99% of the cases.


 Currently D 'in Obj p' "behaves as" the rarely-used 'Obj *const p' 
 and not as the widely and common 'const Obj *p' of C++ ("behave 
 as" because I use pointers instead of references to illustrate the 
 underlying behavior and C++ references are always const).

 Const is another level of protection against unintended behavior 
 (i.e. bugs). In C++, const *can* be circumvented but one has to be 
 horribly explicit to do that. No way you would unintentionally do 
 that.




 So everyone repeat after me ... D is not C++, D is not C++, D is 
 not C++, ...  ;-)




 I know that Derek. Just that *many* of the users that come to D, 
 don't know if you realize it, comes from the C++ world. It's 
 understandable, we like the features of C++ but hate the syntax (and 
 other stuff) and we see D as a better C++. It's perfectly natural to 
 try to achieve the same things in D that we've achieved in C++. 
 Don't be afraid, I'd hate to see D become another C++ (and that's 
 not gonna happen for sure).

 For C++ users, 'in' parameters (for references) are 'const Obj &o', 
 inout/out parameters are 'Obj &o'. When you see that on a signature 
 you can be "sure" (there's always some reasonable trust in the 
 middle) the function will not modify the object (you don't care 
 about the object reference). In D in/out/inout are just a 
 disappointment (for C++ users). I've dreamed to see that keywords 
 used with the same meaning as what I've mentioned above.


 --Derek Parnell
 Melbourne, Australia





 "D is not C++" implies the following:
 Don't try to achieve things the same way as in C++!!

 It's not just the syntax that's different, it's a lot of features too.
 For example: objects are always by reference, never by value.
 This make for a huge difference; it results in a completely different 
 behaviour in many situations. (for the better).

 I would advice you to try Java for a while, maybe it can help you get 
 rid of useless C++ idioms. :)



 I work with JAVA as well. I like it as a language but I hate its VM, 
 its gigantic JDK and its slowness. Native compiled Java would be great 
 if you ask. Anyway I think I get your point.
 Just a few questions, is in/out/inout useful for you in any way? 
 Wouldn't it be more honest to remove in/out/inout and replace it for 
 some kind of 'byref' attribute?

 Regards,
 -- 
 Tom;


 
 This is just my opinion .. I don't think it's a big deal though, but 
 since you asked, here's what I think:
 I think a "ref" or "byref" keyword would be more meaningful than "inout".
 "in" is the default and shouldn't need a keyword anyway.
 "out" is somewhat similar to inout (see my post/question in the learning 
 NG); it offers no special functionality, and I think it's rarely ever 
 used. so it's really not needed.
 
 PS: "in" and "out" would still be keywords; they're used in function 
 contracts.


Now, at last what I wanted to hear. That's my point with "true" 
in/out/inout attributes. I mean attributes that aren't useless.
I would propose two options: remove in/out/inout and introduce some 
'byref' or make in/out/inout act as they should with reference types 
(protecting the referenced objects).

This is also just my opinion and isn't a big deal either, just some 
thoughts.
May 21 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 21 May 2006 13:36:33 +1000, Hasan Aljudy <hasan.aljudy gmail.com>  
wrote:



 huh? if you pass an object reference as in you shouldn't be able to  
 manipulate the object?!!


Why not? What is the axiom that makes this so?


 In what sense is that a "true" in?


There *is* no "true" 'in'. Each language has its own definition of 'in'.  
In D the 'in' just means you can't modify what ever has been passed to the  
function. And in the case of objects and arrays, it's the reference that  
is passed - thus you can't change the reference. There is nowhere that  
talks about protecting that which is referenced - only the reference  
itself.

If we learn to live with this, we can design our code around such a  
concept.

Personally, I'd like the compiler to be a bit more helpful so I could tell  
it when I'm not intending something to be changed and it could tell me  
when it happens to detect that I'm accidently trying to change it.

-- 
Derek Parnell
Melbourne, Australia
May 21 2006
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
I think you misunderstood me.
I'm ok with the current meaning of in/inout.

Derek Parnell wrote:

 On Sun, 21 May 2006 13:36:33 +1000, Hasan Aljudy 
 <hasan.aljudy gmail.com>  wrote:
 
 

 huh? if you pass an object reference as in you shouldn't be able to  
 manipulate the object?!!


 
 
 Why not? What is the axiom that makes this so?
 

 In what sense is that a "true" in?


 
 
 There *is* no "true" 'in'. Each language has its own definition of 
 'in'.  In D the 'in' just means you can't modify what ever has been 
 passed to the  function. And in the case of objects and arrays, it's the 
 reference that  is passed - thus you can't change the reference. There 
 is nowhere that  talks about protecting that which is referenced - only 
 the reference  itself.
 
 If we learn to live with this, we can design our code around such a  
 concept.
 
 Personally, I'd like the compiler to be a bit more helpful so I could 
 tell  it when I'm not intending something to be changed and it could 
 tell me  when it happens to detect that I'm accidently trying to change it.
May 21 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"ChristopheBourez" <ChristopheBourez_member pathlink.com> wrote in message 
news:e4kik9$1ntj$1 digitaldaemon.com...


 It should be interesting to have a const'ness ala C++, I mean, the ability 
 to
 declare methods that do not modify the state of objects.
 Any comments?


I think it's all just a convoluted mess.  Considering how many levels of 
const-ness you can have (can I modify the reference?  or the contents 
thereof?  how about arrays?  can I change their contents, or just where they 
point?), and the obvious problem that you can cast it away (without the need 
for ASM, something Tom mentioned), I don't see how it could be implemented 
orthogonally while still being useful.  Const also means different things to 
different people, so there'd be a lot of dissention over exactly what it 
should do.

Having taught myself how to program C++ from a relatively old book, I never 
really learned to write "const-correct" code.  Even so, having written some 
C++, and a lot more in D, I've _never_ run into a bug caused by my 
modification of something that I wasn't supposed to be modifying.  I'm sure 
some people have, but the concept of "const" seems like an overkill solution 
for it.

I really don't want to see D code looking like some C++ code, where const is 
applied to absolutely _everything_:

const int[] const func(const float x, const char[] const str) const;

Wheeeeeee.
May 20 2006
next sibling parent Tom <ihate spam.com> writes:
Jarrett Billingsley escribió:

 "ChristopheBourez" <ChristopheBourez_member pathlink.com> wrote in message 
 news:e4kik9$1ntj$1 digitaldaemon.com...
 

 It should be interesting to have a const'ness ala C++, I mean, the ability 
 to
 declare methods that do not modify the state of objects.
 Any comments?


 
 I think it's all just a convoluted mess.  Considering how many levels of 
 const-ness you can have (can I modify the reference?  or the contents 
 thereof?  how about arrays?  can I change their contents, or just where they 
 point?),


Implementation difficulty: VERY MUCH.


 and the obvious problem that you can cast it away (without the need 
 for ASM, something Tom mentioned),


That isn't a problem at all. If one do cast constness away one always do 
that VERY explicitly. So it's not an issue been allowed to do that 
meanwhile it's not easy to do it by mistake. Obviously, the C++ cast to 
do this isn't that simple to be written by mistake.


 I don't see how it could be implemented 
 orthogonally while still being useful.


It is useful. But I agree, it's difficult though if we could have just a 
subset of these constness capabilities it would be nice and 
not-that-hard to make it true.

For example, methods that aren't allowed to modify the object. This 
isn't a big deal I guess (to implement I mean).
True IN parameters aren't a big deal either.
The rest may stay below the magnifying glass for a while.


 Const also means different things to 
 different people, so there'd be a lot of dissention over exactly what it 
 should do.


I can't agree with you. With that kind of thought I can say that IN 
parameters mean a really different thing in D than what they mean to me. 
So why would we have to read documentation and learn the language? we 
can make a language that doesn't need training because all of its 
features are universally known from the cradle.


 Having taught myself how to program C++ from a relatively old book, I never 
 really learned to write "const-correct" code. 


It isn't really that difficult, believe me.


 Even so, having written some 
 C++, and a lot more in D, I've _never_ run into a bug caused by my 
 modification of something that I wasn't supposed to be modifying.  I'm sure 
 some people have, but the concept of "const" seems like an overkill solution 
 for it.


Not at all, it is a very nice solution. I did see const helping a lot 
preventing bugs (in my experience).


 I really don't want to see D code looking like some C++ code, where const is 
 applied to absolutely _everything_:
 
 const int[] const func(const float x, const char[] const str) const;
 
 Wheeeeeee. 


That I agree. That's why we should have just a subset of C++ constness 
in D. I hate the constness been dragged along with the type everywhere.

--
Tom;
May 20 2006
prev sibling parent ChristopheBourez <ChristopheBourez_member pathlink.com> writes:
In article <e4ojvc$ppj$1 digitaldaemon.com>, Jarrett Billingsley says...

"ChristopheBourez" <ChristopheBourez_member pathlink.com> wrote in message 
news:e4kik9$1ntj$1 digitaldaemon.com...


 It should be interesting to have a const'ness ala C++, I mean, the ability 
 to
 declare methods that do not modify the state of objects.
 Any comments?


I think it's all just a convoluted mess.  Considering how many levels of 
const-ness you can have (can I modify the reference?  or the contents 
thereof?  how about arrays?  can I change their contents, or just where they 
point?), and the obvious problem that you can cast it away (without the need 
for ASM, something Tom mentioned), I don't see how it could be implemented 
orthogonally while still being useful.  Const also means different things to 
different people, so there'd be a lot of dissention over exactly what it 
should do.

Having taught myself how to program C++ from a relatively old book, I never 
really learned to write "const-correct" code.  Even so, having written some 
C++, and a lot more in D, I've _never_ run into a bug caused by my 
modification of something that I wasn't supposed to be modifying.  I'm sure 
some people have, but the concept of "const" seems like an overkill solution 
for it.

I really don't want to see D code looking like some C++ code, where const is 
applied to absolutely _everything_:

const int[] const func(const float x, const char[] const str) const;

Wheeeeeee. 


I was just mentionning the possibility to define methods that do not modify the
internal state of an object, in order to prevent the implementer to modify
inadvertently its object. If it should be the case, the implementer should be
faced to a contradiction: solving this contradiction does not mean necessary to
drop the const'ness of the method. This may also mean a design error. You are
arguing that you never learned to write const-correct code. You are arguing that
you _never_ had bugs... as long as you develop and maintain your own code
without sharing it with another people. For my part, I will argue to you the
exact opposite. I develop in C++ for 12 years, applying the const'ness all the
time. I do not say to redo what C++ does. I do not avan state that C++ provides
an ideal solution for the const'ness concept. It is not a reason for purely and
simply ignoring this concept.

Christophe
May 21 2006
prev sibling parent Sjoerd van Leent <svanleent gmail.com> writes:
ChristopheBourez schreef:

 It should be interesting to have a const'ness ala C++, I mean, the ability to
 declare methods that do not modify the state of objects.
 
 class X 
 { 
 public:
 void ModifyState?();
 void DontModifyState?() const;
 };
 
 Any comments?
 
 Christophe
 
 


Endless discussion which has followed on this, discussing pros and cons 
about D vs. C++ and so forth.

What about the following:

using another parameter such as:

locked

void foo(in locked Bar bar) {
	bar.setValue(10); // Compiler error
	int i = bar.getValue(); // OK
}

The keyword would modify the behaviour from in, which only is about the 
actual stack value passed to the function, to be completely locking all 
calls (changing the reference, changing the object contents, changing 
the contents within the object contents etc).

It would be possible using the same keyword prepended in front of 
functions themselves:

class Bar {
	int _i;
	void setValue(int i) {_i = i;}

	// Can't modify _i contents nor (if a reference) the
	// contents within.
	locked int getValue() {return _i;}

}

How about this?
May 25 2006