--- Comment #8 from Steven Schveighoffer <> 2010-11-01 
12:47:25 PDT ---
I look at invariants differently than you do I guess.  To me, an invariant is a
self-checking mechanism that says "Every public function is going to leave this
item in a sane state, and therefore, every public function should expect this
to be in a sane state".  It should not be possible for a user who is using a
struct to break an invariant unless they violate the type system.

To me, T.init should always pass the invariant because the user is allowed to

T t;

And this is guaranteed by the language.  Therefore, it's always part of the
public interface.

In other words, invariants are more to protect the user against the struct
misbehaving, not to protect the struct against the user misbehaving.

For example, a poorly constructed invariant:

struct S
  public int i;
  { assert(i == 0); }

This looks to me like what you are doing -- ensuring the user has not mucked
with your struct data.  What an invariant really should do is ensure that the  
struct has not mucked with the struct data.  If the user does it, they do so at
their own risk.

It would be like expecting the invariant of a class to assert the reference is
not null first.

And really, what is the difference between a segfault and an assert error? 
Both should halt execution, and both should print out a valid stack trace.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to