www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Issue with contracts and assertions

reply Andre <andre s-e-a-p.de> writes:
Hi,

for the attached code I noticed some strange behaviors.
I compile the programm with: dmd main -unittest
The expected assertion of the method c pre condition is
not raised.
It is only raised if class A not implements interface I.

On the otherside the commented assertion in the invariant is working
fine.

Is this a bug?

Kind regards
André


interface I {
	void c();
}

class A : I {
	invariant() {
		//assert(false, "Assert INVARIANT"); // Working
	}

	void c()
	in {
		assert(false, "Assert IN");
	}
	body {

	}
}

unittest {
	A a = new A();
	a.c();
}

void main(){}
May 23 2014
parent reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Friday, 23 May 2014 at 13:45:07 UTC, Andre wrote:
 Hi,

 for the attached code I noticed some strange behaviors.
 I compile the programm with: dmd main -unittest
 The expected assertion of the method c pre condition is
 not raised.
 It is only raised if class A not implements interface I.

 On the otherside the commented assertion in the invariant is 
 working
 fine.

 Is this a bug?

 Kind regards
 André


 interface I {
 	void c();
 }

 class A : I {
 	invariant() {
 		//assert(false, "Assert INVARIANT"); // Working
 	}

 	void c()
 	in {
 		assert(false, "Assert IN");
 	}
 	body {

 	}
 }

 unittest {
 	A a = new A();
 	a.c();
 }

 void main(){}
I'm not sure. An implementation shouldn't be allowed to have stricter pre-conditions than it's base class or interface. On the other hand it should be able to relax them.
May 23 2014
parent reply Andre <andre s-e-a-p.de> writes:
Am 23.05.2014 16:34, schrieb Rene Zwanenburg:
 On Friday, 23 May 2014 at 13:45:07 UTC, Andre wrote:
 Hi,

 for the attached code I noticed some strange behaviors.
 I compile the programm with: dmd main -unittest
 The expected assertion of the method c pre condition is
 not raised.
 It is only raised if class A not implements interface I.

 On the otherside the commented assertion in the invariant is working
 fine.

 Is this a bug?

 Kind regards
 André


 interface I {
     void c();
 }

 class A : I {
     invariant() {
         //assert(false, "Assert INVARIANT"); // Working
     }

     void c()
     in {
         assert(false, "Assert IN");
     }
     body {

     }
 }

 unittest {
     A a = new A();
     a.c();
 }

 void main(){}
I'm not sure. An implementation shouldn't be allowed to have stricter pre-conditions than it's base class or interface. On the other hand it should be able to relax them.
In case there is a reason that the assertion is not run, if feels very dangerous for me that all assertions can be disabled by mistake just by adding an interface to a class. At least a compiler messsage should be thrown to warn about "useless" assertions Kind regards André
May 23 2014
parent reply "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Friday, 23 May 2014 at 14:38:27 UTC, Andre wrote:
 Am 23.05.2014 16:34, schrieb Rene Zwanenburg:
 In case there is a reason that the assertion is not run,
 if feels very dangerous for me that all assertions can be
 disabled by mistake just by adding an interface to a class.

 At least a compiler messsage should be thrown to warn about
 "useless" assertions

 Kind regards
 André
I completely agree. A quick search on the issue tracker shows there are some serious bugs involving in contracts and interfaces[0]. It's probably best to keep away from them until the situation improves. [0]: https://issues.dlang.org/buglist.cgi?quicksearch=in%20contract%20interface
May 23 2014
parent Andre <andre s-e-a-p.de> writes:
Am 23.05.2014 16:44, schrieb Rene Zwanenburg:
 On Friday, 23 May 2014 at 14:38:27 UTC, Andre wrote:
 Am 23.05.2014 16:34, schrieb Rene Zwanenburg:
 In case there is a reason that the assertion is not run,
 if feels very dangerous for me that all assertions can be
 disabled by mistake just by adding an interface to a class.

 At least a compiler messsage should be thrown to warn about
 "useless" assertions

 Kind regards
 André
I completely agree. A quick search on the issue tracker shows there are some serious bugs involving in contracts and interfaces[0]. It's probably best to keep away from them until the situation improves. [0]: https://issues.dlang.org/buglist.cgi?quicksearch=in%20contract%20interface
): I found my issue: https://issues.dlang.org/show_bug.cgi?id=12321 I just think about whether it is possible to build a contracts library similiar to C4J (Contracts 4 Java). I like the classed based approach. Kind regards André
May 23 2014