preparing for const, final, and invariant

[Daniel Keep]

Derek Parnell wrote:
> On Sun, 20 May 2007 14:53:54 -0400, Regan Heath wrote:
> 
>> Walter Bright Wrote:
>>> Do not use 'in' if you wish to do any of these operations on a 
>>> parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be 
>>> backwards compatible.
>>>
>>> Adding in all those 'in's is tedious, as I'm finding out :-(, but I 
>>> think the results will be worth the effort.
> 
> .... 
> 
>> Why not make this implicit 'in' parameter 'scope const final' avoiding
>> the need to explicity say 'in' everywhere?
>>
>> My reasoning is that I think 'scope const final' should be the default
>> for parameters as it's the most commonly used and safest option for
>> parameters.  People should use it by default/accident and should have
>> to explicitly opt out in cases where it makes sense.  These cases
>> would then be clearly, visibly marked with 'out', 'ref' etc
> 
> Thanks Regan, your proposal sits very comfortably with me. 
> 
> I have no problems with adding the 'ref' (whatever) keyword in those cases
> where an implicit 'in' (a.k.a. 'scope const final') causes the compiler to
> complain.

The only thing I'm concerned about is having a way of specifying "not
scope const final".  I'm happy to have "safe-by-default", but there
should be a way to escape it.

Maybe lack of type annotations on an argument could be taken as "scope
const final"; adding any annotations manually disables this (so if you
use "const int foo", then it really means "const int foo" and not "scope
const final const int foo".  Then, we can use "in" to mean "just in;
nothing else."

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/