mconst

Thanks for writing this all up! I think this is a big improvement over the previous design -- even if we end up making changes later, this seems usable enough...

> This doesn't change the semantics of the R-values themselves though -- they still are allowed make copies if legal and useful. Otherwise they behave exactly as a const &...

Yup, that's allowed!

I've been warming up to the idea of referring to all `:!` values as "constants", and the ones with `template :!` as "template constants". Some things I like about this...

That's a good question. `HERE4` does feel like the most consistent to me, and it reads pretty well with `ref` (assuming that's not the default); I think it's just `copy`...

If we go with this approach to `for`, I think the way we'd define it is to say that a `ref` annotation on a range also applies to the elements...

(In your second example, was the first `Y.T` supposed to be `X.T`?) I think it's okay to require `observe` in some or all of these cases if that makes things...

Thanks for splitting this off into a separate issue! In https://github.com/carbon-language/carbon-lang/pull/17#discussion_r428333473, you wrote: > We need to decide to what extent we want to worry about the second class of...

Ah, yeah, doing the frees after the fsync() seems like a nice approach! You'd also have to redo them when opening the database, because they wouldn't get persisted, right? But...

> There's a `Drop` implementation on `TransactionalMemory` which persists outstanding non-durable commits. I think it can persist the frees, so that they didn't need to be replayed when the database...