Why callers should explicitly document storage classes

[Brad Roberts]

On Sunday, August 14, 2011 2:30:39 PM, Jonathan M Davis wrote:
> On Sunday, August 14, 2011 23:20:12 Timon Gehr wrote:
>> On 08/14/2011 10:36 PM, Jonathan M Davis wrote:
>>> On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote:
>>>> On 08/14/2011 10:00 PM, Vladimir Panteleev wrote:
>>>>> On Sun, 14 Aug 2011 22:48:18 +0300, Timon Gehr<timon.gehr at gmx.ch>  
> wrote:
>>>>>> requiring lazy before lazy arguments basically destroys the reason
>>>>>> for
>>>>>> lazy being in the language:
>>>>>>
>>>>>> int foo(lazy 2*3);
>>>>>>
>>>>>> is not better than
>>>>>>
>>>>>> int foo({return 2*3});
>>>>>
>>>>> What about requiring "lazy" only for non-pure delegates?
>>>>
>>>> Actually I would rather require lazy arguments to be pure, so that
>>>> they
>>>> can be guaranteed to be executed at most once.
>>>
>>> That still wouldn't be guaranteed, since pure function calls are only
>>> optimized out if they're strongly pure and in the same expression. You
>>> can't rely on calls to pure function
s being optimized.
>>>
>>> - Jonathan M Davis
>>
>> My point was, that if lazy arguments were required to be pure, such a
>> thing _could_ then be guaranteed independently from optimizations that
>> may or may not take place on general pure functions.
> 
> Yes. In theory. It would depend on what Walter was willing to do with the 
> language and the compiler though. At present, pure is purely an optimization 
> and not use to affect semantics at all.

The pure keyword doesn't _change_ semantics, but it very much affects 
semantics, through restriction and the guarantees it provides.  The 
restrictions help enforce some very specific and broadly useful 
behaviors.  But you know this.
 
> However, I'd actually argue that lazy delegates should be effectively treated 
> as pure anyway. Conceptually, what you're doing is delaying the execution of 
> the expression in case it isn't needed. I don't see any reason why the end 
> result should be any different from passing a non-lazy a
rgument. As such, the 
> lazy argument should only be called once regardless. It wouldn't surprise me 
> at all if the implementation doesn't work that way, but I'd argue that it 
> should regardless of purity. From the standpoint of the function, the lazy 
> argument is just like any other argument in terms of its value, and IMHO it 
> should be treated that way.

That's not the way it behaves, or is defined to behave.  Lazy 
parameters are executed 0-N times, entirely based on the implementation 
of the method itself.  It _could_ be re-done to mean 0 or 1, but that's 
still not always 1.  If it was, might as well kill the lazy concept.
 
> - Jonathan M Davis