Feature request: Make "in" blocks part of the public interface

[Timon Gehr]

On 11/25/2012 02:23 PM, monarch_dodra wrote:
> This is mostly related to the discussion that took place on page 2 of
> this thread:
>
> http://forum.dlang.org/thread/ezjiwnydlhtwqoemrmxn@forum.dlang.org?page=2
>
> The issue (as I see it), is that the "contract blocks" in/out, are meant
> to verify the data that is passed to and from the function, rather than
> verify the implementation of said function.
>
> The problem is that it's "conditional execution" is tied to the release
> mode of the compiled function, as opposed to the release mode of the
> caller's code.
>
> This means that if you are using somebody else's lib, his code will
> gladly accept your erroneous data, and crash, with no warning to you.
>
> An obvious example would be the (theoretical) sqrt methods, that could
> restrict via "in" that the input is positive: Once they are written and
> fully verified, they are compiled and released in release mode. But that
> doen't mean somebody using it in his new code won't accidently call it
> with a negative number... and sqrt will fail to see it.
>
> --------
> I'd like to request (but I don't know how feasable this is), that
> "in/out" blocks be made part of the public interface of a function, and
> that it be compiled by the *caller* code (according to his flags), and
> *not* the function itself.

Relevant related issues:

http://d.puremagic.com/issues/show_bug.cgi?id=6549
http://d.puremagic.com/issues/show_bug.cgi?id=6857

It is not obvious how to handle out contracts though. (it is easy if you 
allow for checking the statically known out contract twice if both 
caller and implementation are in debug mode, but that is not satisfiable.)