Stepping back and looking at constness from another angle.

[Don Clugston]

Bruno Medeiros wrote:
> David B. Held wrote:
>> Regan Heath wrote:
>>> [...]
>>> - local variables are (until manually/explicitly assigned to another 
>>> such)
>>> the 1st and only copy/reference of/to the data.
>>>
>>> - function parameters are implicitly a copy/alias of data.  Once you 
>>> have
>>> aliases you have complication and once you have complication you greatly
>>> increase the chances of unexpected changes and therefore bugs.
>>> [...]
>>
>> Ok, Bruno probably won't like this, but he makes a great point about 
>> orthogonality.  The killer argument for orthogonality, IMO, is 
>> generics.  Remember that function argument lists are type tuples.  If 
>> we say that function arguments are const by default, that means that a 
>> given type tuple has different meanings depending on whether it is 
>> used in a function argument context or a non-function argument 
>> context.  In fact, it could have exactly the *opposite* meaning, which 
>> would be the worst kind of non-orthogonality.  This may seem like a 
>> faraway problem, because I don't believe you can construct functions 
>> by assembling type tuples and pasting them onto bits of code.  But if 
>> we cement in this bit of non-orthogonality, we guarantee that such a 
>> feature is either awkward or impossible in the future.
>>
>> Dave
> 
> Just for the record, I'm not an unconditional fan of orthogonality 
> (otherwise I'd be using LISP-family languages). There are various 
> syntactic sugars, and also "semantic sugars", that breach orthogonality 
> but are useful and practical enough to justify them. What I am 
> unconditionally against are orthogonality breaches that serve little or 
> no useful purpose, like some of the examples mentioned in the other 
> thread (like static arrays).
> As for this issue, I guess we all agree that there are two beneficial, 
> but apparently mutually exclusive aspects:
> * The added safety of const-by-default (or syntactic sugar, depending on 
> how you see it).
> * The kept orthogonality of declaring function parameters with tuples.
> Which aspect do I prefer? I'm not sure yet. Frankly, I'm hoping we could 
> come up with a solution that didn't require sacrificing one over the 
> other (or at least minimized that).

Agreed, but I wonder if the second aspect is realistic. There are several other 
issues besides constness. It sounds as though 'ref' variables will be added. But 
there are others. For example, lazy parameters and non-tuple varags are two 
function parameters that would need to become valid variable declarations.