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

Only it isn't "{ expression }" it is: "{ expression }()".

Oskar Linde wrote:
> BCS wrote:
> 
>>Hot, Dog!!!
>>
>>This is a project I was hoping to get to a LONG time ago. (The d code
>>side, not the getting-D-to-do-this side)
>>
>>Best I came up with was a Runtime version.
>>
>>http://www.webpages.uidaho.edu/~shro8822/unit.d
>>
>>Mind if I try to graft in a "few" ;) more units and some unittest?
> 
> Certainly not. Feel free to go ahead. :)
> 
> But as I said, this is just a quick hack. Some improvements would be a
> generic Quantity supporting an arbitrary number of dimensions and rational
> exponents.
> 
> /Oskar

I think 7d is actually more than is needed (But I'm no expert). Mine only used 5d (mole is unit less and candle is power/area). Also I can't ever remember ending up with non integer powers on a dimension.

As it stands, the template provides a lot of functionality.

I think that the next thing to be added should be a set of function (sqrt, pow, etc). Any thought on how to get them to work without having them be wrappers?

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!"

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

Derek Parnell wrote:
> 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 is a feature I would certainly be using. It can't do any harm but can have extremely positive effects.

"Ivan Senji" <ivan.senji_REMOVE_@_THIS__gmail.com> wrote:
> Derek Parnell wrote:
>> 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 is a feature I would certainly be using. It can't do any harm but can have extremely positive effects.

I'll chime in with a resounding "me, too". Having in, out, inout or lazy marked at the place of calling would help returning to the same code later.

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

I misunderstood you. I didn't catch the optional bit. Sorry.

So there is IFTI for member functions functions now...I'm a little late, but thank you and Oskar Linde!! This is amazing. Also the lazy thing, it's great.

Walter Bright wrote:
> The implicit conversion to delegate just broke too much. Instead, I'm trying out Tom S.'s suggestion of using a 'lazy' parameter storage class.
> 
> http://www.digitalmars.com/d/changelog.html

Walter Bright wrote:
> Yes, it would be the same. But I think the interface should be set by the definition, not the use. That's the usual practice with programming languages, and I've never seen it raised as an issue before.

By that logic, shouldn't I be able to pass a delegate to a function with pass-by-value semantics and have the delegate get automagically called and converted into a value?

Assuming that you'll answer "no," they why is it ok for it to work the other way around?