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
