DMD 0.166 release

[Derek Parnell]

On Sat, 02 Sep 2006 12:22:45 -0700, Walter Bright wrote:

> Derek Parnell wrote:
>> On Fri, 01 Sep 2006 10:59:18 -0700, Walter Bright wrote:
>> 
>>>> suggestion that in/out/inout be 
>>>> specified at the call side as well.
>>> Yes, it would be the same. But I think the interface should be set by 
>>> the definition, not the use. 
>> 
>> Yes we agree. But the purpose of this suggestion is not to 'set the
>> definition' but to 'document the usage' of the definition. The purpose is
>> to help both the compiler and human reader to validate the intention of the
>> coder. The definition would still be set when declaring the function but if
>> the compiler optionally allowed parameter storage class keywords at the
>> point of invocation, you could help ensure that the coder is doing what she
>> intended to do. It is a form of DbC.
> 
> Setting the behavior at both the point of definition and point of use 
> may result in fewer programming bugs, it does so at the risk of making 
> modifications harder and annoying programmers.


Why is it so hard to make my thoughts known to you? 

I did *not* talk about "Setting the behavior at both the points". *THE*
behavior is set at the declaration just as it is now. A new *AND OPTIONAL*
behavior can be set at point of use. This new behavior of the compiler
would be such that if no parameter storage class is used for a parameter
then the compiler does nothing new (the default case). If the coder chooses
to include an 'in', 'inout', 'out' or 'lazy' at the point of use then the
compiler could ensure that the coder's belief in how the declararion
signature is can be tested by the compiler and alert the coder to any
mismatch. 

This *will* result in fewer bugs at the 'cost' of making the code easier to
understand when read by a human. How is it annoying? If the coder chooses
to use this feature then obviously they are not annoyed by it. If a future
coder does not like this DbC feature then they can remove it, just as they
can remove all those annoying "in{} out{} body{}" phrases.

>>> That's the usual practice with programming 
>>> languages, and I've never seen it raised as an issue before.
>> 
>> So what? You are in the wonderful position of creating a useful and superb
>> tool that can be very special. You have been a trail blazer and can
>> continue to be one.
> 
> If people don't like adding { } around the lazy expressions, they aren't 
> going to like putting 'lazy' in front of them, either. Every time I've 
> seen a feature like this, the complexity was at the definition point, 
> *not* the use point.

You seem to be think that this would be a mandatory requirement of the
language where as I'm consistantly talking about optional, coder chosen,
stuff. 

For example, I willing choose to use syntax that is 'wordier' in order to
increase the ability of other humans to understand what I was intending by
my coding. If you or anyone else choose not to do that, then fine.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"