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

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.

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

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

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

"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?

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

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

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.

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;