DMD 0.166 release

[Chris Nicholson-Sauls]

Derek Parnell wrote:
> 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.
> 

I admit that I must have misunderstood as well, but looking at it this way I actually feel 
supportive.  This actually strikes me as similar to our already-optional 'override' 
attribute, which asks the compiler to ensure that our method actually does override a 
parent method.  And if it does not, the compiler issues a helpful error.  "Yay!  Now we 
have an alert for API changes!"

I see the ability to *optionally* apply in/out/inout/lazy redundantly at the caller as 
living in the same usefulness category.  It would alert to API changes, and would make it 
clear that the call expression is reliant on the callee exhibiting certain behavior.

I think I would probably use this, albeit sparingly.

-- Chris Nicholson-Sauls