Proposal to add 'Elements of Programming' Concepts to std.traits

[Jonathan M Davis]

On Sunday, June 17, 2012 09:04:16 Philippe Sigaud wrote:
> On Sun, Jun 17, 2012 at 8:42 AM, Jonathan M Davis <jmdavisProg at gmx.com> 
wrote:
> > It wouldn't be. No public function was called. All you did was access the
> > public member variable. Having public members and invariants at the same
> > time doesn't work very well.
> 
> If I change
> 
> int value;
> 
> to
> 
> private int value;
> 
> it can still be accessed through alias this (I guess) and no invariant
> is called.

Well, I'm not sure if it's supposed to be legal to access value like that if 
it's private, but public or private has nothing to do with the invariant in 
this  case. The invariant only runs when you call public _functions_ (it may 
be run with package and protected as well - I don't recall - but never with 
private). It's run before and after they're executed. You're accessing a 
member _variable_. That's why the invariant isn't run. It doesn't matter what 
the access level of a variable is, the invariant is never run just because you 
accessed it. That's why if you want to be able to guarantee your invariants, 
you should never have public member variables on types with an invariant. And 
if alias this allows you to expose a private member variable, then it's in the 
same boat as a public one. Invariants and public member variables just don't 
mix.

- Jonathan M Davis