I hope this isn't too much of a tangent, but I wonder how D's choices fall: http://dlang.org/const3.html
It has a deep const view and deep immutability (no shallow notion for either), almost no inference, and it permits casting away the invariants but claims undefined behavior in those cases and could (probably) disallow them. On Fri, Aug 9, 2013 at 12:54 AM, Jonathan S. Shapiro <[email protected]>wrote: > On Thu, Aug 8, 2013 at 5:05 PM, David Jeske <[email protected]> wrote: > >> I'm not going to use the LISP-esq cons, because I reject the notion that >> this solution is a material product of the cell type declarations. >> > > Unfortunately, it *is* a product of how the container data structure is > implemented. By "whistling away" the container data structure, you > eliminated much of the point I was trying to make. > > Please bear with me and do it with a LISP-style list first. There's a > method to my madness. Also, please do NOT mix up the meanings of const and > deep const. They are very different things, and if you to swap all the > terminology around on the fly we'll *never* keep the conversation > straight. Please resist the temptation to do that, even if chopping off all > of your fingers is what it takes to discipline yourself. It's *that* important > in these kinds of conversations. > > I'm also going to demonstrate const/readonly only, since immutability is a >> product of there being only const/readonly references alive. >> >> A generic list of readonly objects >>> >> >> var alist = new List<const Foo>(); // const means deep-const >> var alist = (List<const Foo>) new List<Foo>(); // this cast should be >> possible >> var alist = (List<Foo>) new List<const Foo>(); // I'm okay if this >> cast is possible >> > > So going through these: > > var alist = new List<deep const Foo>() > > is fine, though it isn't at *all* obvious that parametrics and mutability > typing interact favorably. > > var alist = (List<deep const Foo>) new List<Foo>() > > is *not* obviously okay, unless you are appealing to a linear typing > intuition. In abstract, I agree that we would *like* this to be okay, but > it's not clear that the subtyping relation you are tacitly relying on is a > valid subtyping relation. Certainly it's a complicated relation that needs > careful soundness analysis before we can take it for granted. > > The last one is just not OK at all. I understand that you personally would > tolerate it, but it defeats the entire purpose of access restriction > typing, and it defeats soundness in the type system. Please desist on this. > readonly/immutable is *not* advisory in this discussion. > > > >> "const Foo" means all fields and returned values from methods are also >> const, and methods which modify Foo or any data reached from Foo can't be >> called since they would require a non-const "this" parameter. The latter is >> more useful with const-inference, so we don't have to manually decorate >> methods with const.. though we could. >> > > Wow. That's not at *all* obvious from a type system point of view. If you > require this, it's nearly certain that the subtyping relation you appealed > to above does not hold. > > >> >> A readonly generic list of mutable objects >>> >> >> One method is not to use const at all for this, as in... >> >> ICollectionReadonly<Foo> alist = existingList.asReadOnly(); >> > > Yes, but that defeats the point of the exercise, and there actually *was* a > point to the exercise as requested... > > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > > -- Alex R
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
