Output contract's arguements

[monarch_dodra]

On Thursday, 19 September 2013 at 17:09:49 UTC, Maxim Fomin wrote:
> 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.

Yes, most probably. I'd much rather have the "in/out contracts 
should be conditionally included depending on caller compilation 
options, the lib's". EG: the reason druntime doesn't do array 
overlap checking, even when compiling in non-release.

> And even if it will be, nothing stops parameter to be modified 
> by function body even it is not known at CT.

I didn't suggest banning modifying function arguments?

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

Just to be clear, I'm not complaining. I wanted to have a clearer 
answer about what the behavior *should* be. To be fair, I 
expected the answer would be "It should probably work that way, 
but it'll never happen, sorry".

> By the way, it seems that you view in/out/body as separate 
> functions, probably like invariant, which is wrong

Why is it wrong? Is there a specification that says it *can't* be 
that way? It'd be (almost) the only way to be able to define 
contracts in interface files, with implementation inside other 
files.

> just take a look into assembly as I asked before.

My original question was "is the behavior according to spec". 
Looking at assembly defeats the question.

> If you want to modify parameter, just create local copy of it.

Yes.

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

Pure theory was the point of my question.

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

I'm perfectly fine if we close this as "won't fix", "for 
practical reasons, arguments passed by value *may* be modified by 
the implementation". As long as we document it right.

> Even this does not solve ref problem.

I'm not sure there is any problems with ref. Reference argument 
would reference the same variable regardless. I'm not asking for 
a time machine to give me the ref's old value.

> 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 think I'm seeing a trend that, regardless of merit or technical 
correctness, changing the behavior excessively costly anyways.

:/