Why callers should explicitly document storage classes

[Jonathan M Davis]

On Sunday, August 14, 2011 17:39:29 Brad Roberts wrote:
> 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.

Oh, I know that it's not always 1, and I'm not suggesting that it always be 1. 
I'm suggesting that it always be 0 or 1, and that it not actually be called 
multiple times even if it's referenced multiple times. I don't see why there 
is any value in having it called multiple times. In concept at least, a non-
lazy parameter is the same as a non-lazy except that it isn't evaluated unless 
it's used. And so I don't see why you'd want to be evaluating it multiple 
times except that it's probably easier to implement that way.

- Jonathan M Davis