www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6549] New: Implement contracts without implementation.

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

           Summary: Implement contracts without implementation.
           Product: D
           Version: D2
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: timon.gehr gmx.ch



currently, code like the following is rejected:

abstract class C{
    int foo(int x)
      in{assert(x<0);}
      out(result){assert(result>0);}
}

tt.d(10): Error: function tt.C.foo in and out contracts require function body.

Which does not make sense, because contracts logically belong to the method
declaration.

Such code should be accepted and the contracts should be subject to contract
inheritance. This will require a tiny grammar change.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 24 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6549


Shahid <govellius gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |govellius gmail.com



I would like a clarification about abstract class/methods with contracts.
Should the bottom two examples be valid D code?

----
// Works ( and documented TDPL/website )
interface I {
        int func( int x )
        in { assert(x == 0); }
}
class C : I {
        int func( int x ) { return x; }
}

// Does not work ( undocumented )
abstract class A
{
        int func( int x )
        in { assert(x == 0); }
}
// ditto
class A2 {
        abstract int func( int x )
        in { assert(x == 0); }
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 28 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6549




Yes, that is the plan.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 28 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6549


Alex Rønne Petersen <xtzgzorex gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xtzgzorex gmail.com



09:17:40 PST ---
Is there any news on this? Design-by-contract in D is seriously crippled due to
this bug.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 12 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6549


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com
           Severity|normal                      |enhancement





 Is there any news on this? Design-by-contract in D is seriously crippled due to
 this bug.


It's an arbitrary restriction, not a bug.

http://www.dlang.org/declaration.html
Decl:
    StorageClasses Decl
    BasicType Declarators ;
    BasicType Declarator FunctionBody
    AutoDeclaration

http://www.dlang.org/function.html
FunctionBody:
    BlockStatement
    BodyStatement
    InStatement BodyStatement
    OutStatement BodyStatement
    InStatement OutStatement BodyStatement
    OutStatement InStatement BodyStatement

InStatement and OutStatement are part of FunctionBody, so if the function has
no body then it can't have in and out contracts.

But I entirely agree that it should be allowed.  Contracts are part of the API,
not the implementation.  As such, they are equally applicable to
abstract/interface methods.  It could also improve contract checking in
closed-source libraries.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 12 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6549




Possible grammar rewrite:

Decl:
    StorageClasses Decl
    BasicType Declarators ;
    BasicType Declarator BlockStatement
    BasicType Declarator BodyStatement
    BasicType Declarator Contracts ;
    BasicType Declarator Contracts BodyStatement
    AutoDeclaration

Contracts:
    InStatement
    OutStatement
    InStatement OutStatement
    OutStatement InStatement

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 29 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6549


Henning Pohl <henning still-hidden.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
                 CC|                            |henning still-hidden.de



PDT ---
https://github.com/D-Programming-Language/dmd/pull/2281

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 30 2013