http://d.puremagic.com/issues/show_bug.cgi?id=1228

           Summary: Class invariants should not be called before the object
                    is fully constructed
           Product: D
           Version: 1.014
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: onlystupidspamhere@yahoo.se


The spec should state whether invariants hold only after the constructor has finished or not. http://www.webber-labs.com/research/paste01.ps contains some discussion about class invariants in Java, and might be helpful.

The following code shows how D currently checks invariants even before the class has been fully constructed. IMO invariants should hold only after the constructor has finished and there is a valid reference to the object.

Code:

import tango.io.Stdout;

class foo {

        this() {
                Stdout("entering constructor").newline;
                bar();
                Stdout("leaving constructor").newline;
        }

        void bar() {
                Stdout("method bar()").newline;
        }

        invariant {
                Stdout("invariant").newline;
        }
}

void main() {
        auto a = new foo();
}

Output:

entering constructor
invariant
method bar()
invariant
leaving constructor
invariant


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1228





------- Comment #1 from braddr@puremagic.com  2007-05-11 14:25 -------
Invariants are checked after every public member function's execution as well, so the behavior you're seeing at least meets the spec.  Now, I can see some arguments for not having invariants checked until construction is complete, but that'd be a change in documented behavior.


-- 

d-bugmail@puremagic.com escribió:
> http://d.puremagic.com/issues/show_bug.cgi?id=1228
> 
> 
> 
> 
> 
> ------- Comment #1 from braddr@puremagic.com  2007-05-11 14:25 -------
> Invariants are checked after every public member function's execution as well,
> so the behavior you're seeing at least meets the spec.  Now, I can see some
> arguments for not having invariants checked until construction is complete, but
> that'd be a change in documented behavior.
> 
> 

Sound reasonable to me, too. You can always refactor to:

class foo {

        this() {
                Stdout("entering constructor").newline;
                barInternal();
                Stdout("leaving constructor").newline;
        }

        void bar() {
                barInternal();
        }

	private void barInternal() {
		Stdout("method bar()").newline;
	}

        invariant {
                Stdout("invariant").newline;
        }
}

http://d.puremagic.com/issues/show_bug.cgi?id=1228





------- Comment #3 from onlystupidspamhere@yahoo.se  2007-05-12 04:11 -------
(In reply to comment #2)
> Sound reasonable to me, too. You can always refactor to:
> 
> class foo {
> 
>          this() {
>                  Stdout("entering constructor").newline;
>                  barInternal();
>                  Stdout("leaving constructor").newline;
>          }
> 
>          void bar() {
>                  barInternal();
>          }
> 
>         private void barInternal() {
>                 Stdout("method bar()").newline;
>         }
> 
>          invariant {
>                  Stdout("invariant").newline;
>          }
> }

This slows down the release build since at least DMD doesn't inline member functions. Yes, this is a design decision and I'm not sure which one is better.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1228





------- Comment #4 from bugzilla@digitalmars.com  2007-07-01 00:38 -------
Since the invariant is called at the start of public or exported members, such members should not be called from constructors. I'll update the documentation to indicate this.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1228





------- Comment #5 from onlystupidspamhere@yahoo.se  2007-07-01 03:05 -------
(In reply to comment #4)
> Since the invariant is called at the start of public or exported members, such members should not be called from constructors. I'll update the documentation to indicate this.

Good, updating the docs works for me.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1228


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




------- Comment #6 from bugzilla@digitalmars.com  2007-07-01 14:02 -------
Fixed DMD 1.018 and DMD 2.002


--