www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 302] New: in/out contract inheritance yet to be implemented

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302

           Summary: in/out contract inheritance yet to be implemented
           Product: D
           Version: 0.165
          Platform: PC
               URL: http://www.digitalmars.com/d/dbc.html
        OS/Version: Windows
            Status: NEW
          Keywords: wrong-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: smjg iname.com


A long-standing unimplemented feature is inheritance of in/out contracts.  From
the spec:

"If a function in a derived class overrides a function in its super class, then
only one of the in contracts of the function and its base functions must be
satisified. Overriding functions then becomes a process of loosening the in 
contracts.

A function without an in contract means that any values of the function
parameters are allowed. This implies that if any function in an inheritance
heirarchy [sic] has no in contract, then in contracts on functions overriding
it have no useful effect.

Conversely, all of the out contracts needs [sic] to be satisified, so
overriding functions becomes a processes of tightening the out contracts."

It's about time we finally got this implemented.  A strategy was proposed at
digitalmars.D:31595, "Implementing contract inheritance".

Existing DStress testcases:
http://dstress.kuehne.cn/run/i/in_out_body_10_A.d
http://dstress.kuehne.cn/norun/i/in_out_body_10_B.d
http://dstress.kuehne.cn/norun/i/in_out_body_10_C.d
http://dstress.kuehne.cn/run/i/in_out_body_11_*.d


--
Aug 21 2006
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major




--
Jun 18 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302


clugdbug yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|wrong-code                  |





This isn't wrong-code. (I agree that it's important, but it's not bad code
generation -- marking this sort of thing as wrong-code makes the wrong-code
keyword useless).


--
Apr 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302






"it's not bad code generation" - how do you work that out?


--
Apr 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302








 "it's not bad code generation" - how do you work that out?


Bad code generation generally means the front-end is sending incorrect data to
the backend; or else there's a bug in the backend. (Also for the case of CTFE,
it can also include bugs in the interpreter; in that case, the frontend is the
backend).

In this case, the bug is really in the spec: the spec states a vague intention
about how contracts should work, but there's never been any attempt whatsoever
to implement it in the compiler. At the very least, the spec should say that
it's not implemented, and I suspect that it should be completely removed from
the D1 spec, unless Walter actually intends to implement it in D1.

I notice that these unimplemented things (array operations was the other
obvious one, but I suspect there are others) all date from the very early days
of D. In modern times, Walter's mostly changed the spec only when he's actually
implemented something.


--
Apr 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302






The spec specifies what the code should do, but the code being generated does
something else. How is that not the very definition of wrong-code?
(This probably falls in the "the front-end is sending incorrect data to
the backend" category)

Never having been implemented doesn't change any of this, IMHO.


--
Apr 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302


clugdbug yahoo.com.au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec







 The spec specifies what the code should do, but the code being generated does
 something else. How is that not the very definition of wrong-code?
 (This probably falls in the "the front-end is sending incorrect data to
 the backend" category)
 
 Never having been implemented doesn't change any of this, IMHO.


I think the problem is in the spec in this case. When it's not implemented, it
should either marked as not yet implemented in DMD, or it shouldn't be in the
spec at all yet. _Every_ other case of wrong-code in bugzilla is different.
The nature of the issue is completely different, so I really think it's
unhelpful to use the same keyword for both.


--
Apr 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302










 The spec specifies what the code should do, but the code being generated does
 something else. How is that not the very definition of wrong-code?
 (This probably falls in the "the front-end is sending incorrect data to
 the backend" category)
 
 Never having been implemented doesn't change any of this, IMHO.


 
 I think the problem is in the spec in this case. When it's not implemented, it
 should either marked as not yet implemented in DMD, or it shouldn't be in the
 spec at all yet. _Every_ other case of wrong-code in bugzilla is different.
 The nature of the issue is completely different, so I really think it's
 unhelpful to use the same keyword for both.


I don't think is a good idea to change the specs according to DMD. DMD is just
an implementation, an incomplete one. It's not serious to change an spec
because an implementation don't implement a feature!

I don't know if this is wrong-code or not, but I know it's not a spec issue, is
a missing feature in DMD.

So please, please, please, don't change the specs, fix the implementation.

Thanks!


--
Apr 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302








 So please, please, please, don't change the specs, fix the implementation.


I entirely agree.  Moreover, I proposed a strategy more than 3 years ago.  So
why is it taking so long?


--
Apr 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302






Isn't it trivial to implement?

---
Foo bar(A a, B b, C c)
{
  try{super.inConstract(a,b,c);}
  catch(Throwable){this.inConstract(a,b,c);}
  //body
  super.outContract(result);
  this.outContract(result);
  return result;
}
---


--
Apr 24 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302






Here's the link to Stewart's original post.

http://www.digitalmars.com/d/archives/digitalmars/D/31595.html

Note that Walter seems to have rejected Stewart's 3rd point, which is part of
the reason I don't think this is a spec bug rather than wrong-code... it's not
clear to me that we know what the correct code is.

The task should be separated into dependent bugs. Stewart's first point should
become a new Phobos bug -- it's something Sean can fix if it still applies.


--
Apr 24 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302






He rejected to call in contract by caller, because it obviously should be
called by callee.

ps yeah, checking this contract before super contract is better :)


--
Apr 24 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com







 Isn't it trivial to implement?


It is, but not by your code because....


 ---
 Foo bar(A a, B b, C c)
 {
   try{super.inConstract(a,b,c);}
   catch(Throwable){this.inConstract(a,b,c);}


There could be any number of classes in the hierarchy between Object and the
type of this.  This would check only the contracts assigned to this.bar and
super.bar, nothing higher up.  Same applies to your out checking code.



 Note that Walter seems to have rejected Stewart's 3rd point,


He didn't.  He merely gave a counter-argument to /one tiny detail/ of point 3. 
Moreover, tweaking what I wrote to put in contract checking on the callee side
is trivial.


 which is part of the reason I don't think this is a spec bug rather 
 than wrong-code... it's not clear to me that we know what the 
 correct code is.


The only spec issues in my post are 4 and possibly 2.  But 2, while nice,
doesn't need to be done just to get this working at a basic level.


 The task should be separated into dependent bugs. Stewart's first 
 point should become a new Phobos bug -- it's something Sean can fix 
 if it still applies.


I don't get you here....



 He rejected to call in contract by caller, because it obviously should be
 called by callee.


Why obviously?

Advantages of in contract checked by caller:
- A library can be compiled in release mode, and programs using the library can
still have the checks that they're using it correctly.
- If a method is called through a base class reference on a derived class
object, it is sufficient to check the base class contract, possibly saving
computational cost.
- Combined with allowing contracts without body, it could enable contracts to
work on closed-source libraries, without forcing the creator to distribute two
versions of the .lib.

Advantages of in contract checked by callee:
- Slightly less code in development builds.
- ....

But at least getting something working is more important than coming to a final
decision on this little detail.  Currently, the spec leaves where to do the
contract checking up to the implementation.


--
Apr 24 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302






Caller can't check descendant contracts, which can succeed.


--
May 04 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302






But if the arguments to a method aren't guaranteed to pass the base class
contracts, one wouldn't be calling it through a base class reference.  Hence my
point.


--
May 04 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=302


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |FIXED



02:10:59 PDT ---
Fixed dmd 1.048 and 2.033

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 06 2009