Suggestion: object const'ness

[Regan Heath]

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