preparing for const, final, and invariant

Bill Baxter dnewsgroup at billbaxter.com
Sun May 20 19:56:32 PDT 2007


Daniel Keep wrote:
> 
> 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."

Ideally, starting from a black slate I'd say 'inout' should remove the 
const/final/scope-ness, instead of what it does now which is to make the 
*pointer* to the object itself modifiable.

Then 'ref' could be used to mean 'i want to pass the pointer by reference'.

So....

void foobulate(MyObject o) {
    o = new Object(); // bad
    o.member = 42; // bad
}
void foobulate(inout MyObject o) {
    o = new Object(); // bad!
    o.member = 42; // ok!
}
void foobulate(ref MyObject o) {
    o = new Object(); // ok!
    o.member = 42; // ok!
}

But that's just my top-of-the-head reaction.  I'm sure there are 
ramifications that I haven't considered.

I just wouldn't like to see 'in' take on a meaning other than "this 
parameter is being passed _in_ and you shouldn't expect to be able to 
get any information _out_ using it"

If it has a meaning of "it's ok to modify the thing being passed in" 
then pretty much the only time it will be used is when you are 
interested in the modification, so basically 'in' would mean "we want to 
get something out", which is nonsensical.

--bb



More information about the Digitalmars-d-announce mailing list