preparing for const, final, and invariant

Johan Granberg lijat.meREM at OVEgmail.com
Sun May 20 14:01:59 PDT 2007


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.
> 
> 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

I agree with this, const by default is a real good idea (TM)




More information about the Digitalmars-d-announce mailing list