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;

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

.
>
> 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

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

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

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 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.
> 

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. :)

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;

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? :)