preparing for const, final, and invariant

[Bill Baxter]

Regan Heath wrote:
> Walter Bright Wrote:
>> Bill Baxter wrote:
>>> Walter Bright wrote:
>>>> Another option is to reuse 'inout' to mean 'mutable', since 'inout' is 
>>>> replaced by 'ref'.
>>> ...which is what my last message was suggesting.
>> You're right, I read your posting too quickly.
>>
>>> Any reason why that wouldn't work?
>> Breaking existing code.
>>
>>> There is the question of what would happen to "out" and 
>>> how you'd get out behavior applied to the pointer rather than the value.
>> I'd leave out as it is.
>>
>>> And while "mutable" is on the table, is D going to have a story for 
>>> private mutable members that don't affect the interface?  Like the 
>>> classic private mutable cache member in C++.
>> Ah, the "logical constness" design pattern. I personally loathe that 
>> <g>. Const but mutable data just smacks of being far too clever.
> 
> My feeling is that if we have 'scope const final' as default and implicit then we do need some way to escape it, as we've all suggested.
> 
> I think the best way is as Daniel suggested, any keyword will override the implicit/default ones, so:
> 
> void foo(int i) {}  //scope, const, final
> void foo(const int i) {} //just const
> ..etc..
> 

That makes sense to me too.  If you don't say anything it's 'scope const 
final'.  But if you do specify something then it's only that.  I'm not 
wild about the aesthetics of !const for parameters, and even less wild 
about the possibility that !const could become common idiom for 
modifiable parameters.  If it's a common way to pass a parameter, then 
there should be a way to express the attribute positively (like 
"mutable" or "variable" or "inout") in terms of what it does do, rather 
than what it doesn't.

--bb