Why callers should explicitly document storage classes

[Timon Gehr]

On 08/14/2011 05:36 PM, Vladimir Panteleev wrote:
> On Sun, 14 Aug 2011 14:34:46 +0300, Mehrdad <wfunction at hotmail.com> wrote:
>
>> Consider this example:
>>
>> // In module foo.d:
>> void baz(bool condition, lazy int value)
>> {
>> if (condition)
>> writeln(value);
>> }
>>
>> // In module bar.d:
>> import foo;
>> bool someCondition() { return false; }
>> void main()
>> {
>> auto vals = [1, 2, 3, 4];
>> while (!vals.empty)
>> baz(someCondition(), items.moveFront());
>> }
>>
>> There is **absolutely NO WAY** to figure out what's wrong at the
>> calling site. You need to check /every/ method call and make sure
>> nothing weird is happening (e.g. lazy), and it's pretty much
>> impossible to figure it out unless you're intimately familiar with the
>> entire library you're calling -- something which (obviously) doesn't
>> scale.
>>
>> I don't know of a similar example off the top of my head for out/ref,
>> but the same idea applies.
>>
>> Is this convincing enough that we need to document storage classes at
>> the CALLING site, rather than just the CALLEE site?
>
> I've raised this issue during voting for std.parallelism. I think the
> consensus was that "lazy" before lazy arguments would be appropriate,
> but "ref" would be mostly pointless, due to complex and reference types.
>

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});