Output contract's arguements

[Maxim Fomin]

On Thursday, 19 September 2013 at 10:29:22 UTC, monarch_dodra 
wrote:
> On Thursday, 19 September 2013 at 08:29:43 UTC, Maxim Fomin 
> wrote:
>>> In particular if/when we will have "contracts are 
>>> managed/compiled by caller", then that behavior is the only 
>>> behavior we will be able to do (AFAIK).
>>>
>>
>> I looks like your misunderstanding based on wrong assumption 
>> about implementation.
>
> Not really a wrong assumption. This *has*. This has been 
> discussed before. Another plan is to allow contracts in 
> interfaces, in which case, there is no associated body:
> http://d.puremagic.com/issues/show_bug.cgi?id=6549

Interfaces are irrelevant here. By the way, taking into account 
current implementation I think you will have to wait a lot of 
time to see the requested satisfied. And even if it will be, 
nothing stops parameter to be modified by function body even it 
is not known at CT.

>
>>> Or is there something that explicitly states it works that 
>>> way? Should I file a bug report? ER?
>>
>> I don't consider that whether out refers to unmodified or 
>> modified parameter is important issue. Current policy should 
>> be just documented and left as it is (unless you provide 
>> significant reasons that current implementation is flawed).
>
> It's flawed because the behavior of the contract will depend on 
> what the body of the function does to copies of data that 
> should be scoped only to that body.

This is deliberately created problem - you modify passed by value 
parameter which has little sense and then you make so that out 
contract should depend on original value of parameter. Now you 
create a problem and complain about it.

By the way, it seems that you view in/out/body as separate 
functions, probably like invariant, which is wrong - just take a 
look into assembly as I asked before. If you want to modify 
parameter, just create local copy of it.

>
> An "out" contract should only verify that the value returned is 
> correct "in regards" to the "input arguments".
>
> This means the implementation details of the function's body 
> are leaking into the out block. That just isn't right.

This is pure theory. Nothing promises you that discussed minor 
implementation detail of out contracts would be implemented in a 
way you expect.

There are several problem arising from your demand:
1) How much sense is in (providing support for) modifying passed 
by value parameter?
2) If parameter is passed by reference and supposed to be 
modified, this would engage into a conflict that original value 
should be preserved in.
3) Implementing your proposal would require - either creating 
three separate functions for in/out/body or putting pressure on 
to function frame stack + available registers for saving original 
values. Even this does not solve ref problem.

And on the advantage part of the proposal there is no reasoning 
except suspicious practice of modifying passed by value 
parameters and your words "I'd like the out contract to operate 
on its own copies of the function's arguments."

Of course, you can issue enhancement request writing that you 1) 
do not want to wake a local copy of parameter and 2) do want to 
modify passed by value parameter and 3) do want to see in the out 
contract original value (thus requiring 4a) either to create 
three separate functions instead of one or 4b trashing 
stack/registers), but I expect it would be closed with boldly 
WONTFIX.

I really doubt someone would write pull for a 'problem' which is 
solvable by:

     size_t ret = 0;
+++ T vv = v;
--- while(v >>= 1) ++ret;
+++ while(vv >>= 1) ++ret;
     return ret;