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