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