On Tue, Mar 22, 2011 at 6:12 AM, Ben Kloosterman <[email protected]> wrote:
> I will bite … Isnt this another reason why we should have member inline > functions and constructors for structs to create quasi classes...? > I agree, but the point is that it's a separate matter. The presence or absence of member functions isn't enough to let us do adequate contract capture w.r.t. mutability. The problem is that member functions can change with successive versions, and that the inferred mutability of fields can change as a result. What this means in practice is that (a) public interfaces cannot rely on implementation for any inferred types, and (b) the issues of mutability and member functions are orthogonal. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
