• iackhtak (14/14) May 13 2015 There was discussion about broken contract programing. Broken
• iackhtak (2/17) May 13 2015 Wrong thread, sorry

"iackhtak" <iackhtak gmail.com> writes:

There was discussion about broken contract programing. Broken 
thing was "in" contract within inheritance. If you add different 
"in"-contract in overridden parent and derived function only one 
will be checked.
I thought that solution is to ban "in"-contract for derived 
function. "In"-contract says what you can pass. If you want to 
accept input without any constraints you can't add new constraint 
in inherited stuff because your inherited stuff can by used in 
any context where base thing can. Within this context any 
arguments can be passed. This way adding new constraints on input 
brakes Liskov substitution principle and have to be banned.
Theoretically it can be allowed to loose contract(and extend 
interface) but the thing looks hard to implement.

Conversely "out" can be narrowed without any restrictions.

"iackhtak" <iackhtak gmail.com> writes:

On Wednesday, 13 May 2015 at 10:18:26 UTC, iackhtak wrote:
 There was discussion about broken contract programing. Broken 
 thing was "in" contract within inheritance. If you add 
 different "in"-contract in overridden parent and derived 
 function only one will be checked.
 I thought that solution is to ban "in"-contract for derived 
 function. "In"-contract says what you can pass. If you want to 
 accept input without any constraints you can't add new 
 constraint in inherited stuff because your inherited stuff can 
 by used in any context where base thing can. Within this 
 context any arguments can be passed. This way adding new 
 constraints on input brakes Liskov substitution principle and 
 have to be banned.
 Theoretically it can be allowed to loose contract(and extend 
 interface) but the thing looks hard to implement.

 Conversely "out" can be narrowed without any restrictions.

Wrong thread, sorry