preparing for const, final, and invariant

[Regan Heath]

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.

Perhaps I have missed the discussion (being away for the last 7 months) which discussed why we don't want 'scope const final' applied to implicit 'in' parameters?

As opposed to requiring explicit 'in' which Walter is proposing.

To explain...

Currently an parameter is implicitly 'in' i.e.
void foo(int a) {}  //a is 'in'

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

>From what I can see we currently have 2 reasons to require explicit 'in' (from Walters post and others in this thread):

1. avoid breaking backward compatibility with D 1.0.

2. parameters will all have parameter specifiers and pedantic people (no offence intended) will enjoy fully specified function parameters all the time.

If so, isn't part of the point in making this change in a beta so that we can ignore reason #1.  Granted if the feature was to be integrated into the mainstream version it would then break backward compatibility, but, imagine the situation:

Old code would cease to compile and would need modification, but, the modifictions required would for the most part simply be the addition of 'out', 'ref', or an added .dup or copy.  Which, in actual fact should have been there in the first place.  Meaning, the exisiting code is unsafe and the resulting code after these changes would be much safer.

In other words, applying 'scope const final' to implicit 'in' will catch existing bugs, but requiring explicit 'in' will not, right?

As for reason #2 I think it's largely aesthetic however..

1. Applying it to implicit 'in' is less typing for those non-pedantic programmers who can live without all parameters having a specifier.  I personally dont think the presence of an explicit 'in' results in clearer code as it is clear to me that unspecified parameters are 'in' (and with these changes would be 'scope const final' too).

Regan Heath