So on to resolutions. First statement: we keep getting this wrong, so whatever capabilities we expose in the language, I really think that we need to build a type system for mutability that let's us check that we have things right. Informal reasoning has proven insufficiently reliable. Bother!
Without having that type system, it still seems possible that we might get by with having only two positions: init-only fields and [deeply] immutable structures. But what is *very* clear is that the two are different, and that the notion of "not mutable via any alias" remains a powerful notion. I have mused previously that we might finesse the issue with a semantics change: - Unboxed locals are advisory, relying on region types for actual unboxing. - Add a keyword to indicate that unboxing is not optional and that failure should result in an error. I don't think this is good language design, but it's useful for thought experiments. It appeared, on first inspection, to solve the problem of lifetimes by allowing stack-allocated things to be heap-allocated without violating the language semantics. Which is all good. Problem is: it doesn't address the problem of inner references. Let's begin with the assumption that we will deal with the problem of lifetime analysis by separate means. I wave my hands here and appeal (in ignorance) to region analysis. It turns out that this is insufficient. The problem is that *even when it is subject to lifetime safety*, and *even when we consider only the single-threaded case*, an init-only field is not immutable.In order for the output of length() to be stable it needs to be immutable. If this is making your brain hurt, you're in very good company. Speaking for myself, I definitely feel like I need to sleep on this. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
