Suggestion: object const'ness

[Tom]

Hasan Aljudy escribió:
> Regan Heath wrote:
>> On Sat, 20 May 2006 20:44:52 -0400, Jarrett Billingsley  
>> <kb3ctd2 at yahoo.com> wrote:
>>
>>> "Tom" <ihate at spam.com> wrote in message
>>> news:e4ll86$q0e$1 at 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;