Stepping back and looking at constness from another angle.

[Derek Parnell]

On Thu, 07 Jun 2007 18:42:03 -0400, Regan Heath wrote:

> Denton Cockburn Wrote:
>> On Thu, 07 Jun 2007 16:25:21 +1000, Reiner Pope wrote:
>> 
>>> Another problem with const by default came to mind. Consider the
>>> following code, with const-not-by-default:
>>> 
>>> void foo( ref const(char)[] c)
>>> {
>>>      c = c[1..$];
>>> }
>>> 
>>> I would hate to see this in const-by-default, which would try to wrap a
>>> const( ) around the whole type. To counter that, you would probably have
>>> to write some mess like
>>> 
>>> void foo ( mutable( ref const(char)[] ) c ) {
>>>      c = c[1..$];
>>> }
>>> 
>>>    -- Reiner
>> 
>> Again, I'm also trying to understand this, knowing that things change a 
>> lot over the course of the discussion. That being said, I thought the 
>> current position is that by adding any other qualifier, such as ref, 
>> const/scope/final is no longer automatically applied.
> 
> I thought so too.  As Don says; 'ref' is an alias of 'inout'.  It's ver
> y purpose is to indicate a variable which is going to be modified.  Therefore it stands to reason that function parameters passed as 'ref' will be mutable by default. :)
> 
> Regan

I have to disagree Regan. 'ref' might mean that the passing mechanism is
"by reference" but it does not necessarily mean that the access permission
is 'allowed to change". Do not get parameter passing mechanics confused
with access permissions.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell