www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feature request: Make "in" blocks part of the public interface

reply "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Nov 25 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.)
Nov 25 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
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
Nov 25 2012