Stepping back and looking at constness from another angle.

[Regan Heath]

Derek Parnell Wrote:
> 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.

You're dead right.  In fact 'ref' (a passing mechanic) is/has replaced 'inout' (signifying 'this reference is allowed to change') so it seems Walter/D is confusing the two.

Regan