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

[Timon Gehr]

On 11/25/2012 02:37 PM, Timon Gehr wrote:
> 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.)

s/satisfiable/satisfactory/g