Remove Freeze

[nikomatsakis]

In the discussion on #11781, it has become clear that there is still a role for Freeze, but likely not the Freeze kind we have today. Today Freeze is a property based on reachability, but this should likely change.

See comment here for details:

#11781 (comment)

[nikomatsakis]

Copying tags and labels from #11781. I can mentor.

[nikomatsakis]

cc @flaper87

[nikomatsakis]

cc @alexcrichton @thestinger

[flaper87]

Since I'm working on the Share kind already, I'll stab this one too. (Although they are quite independent)

[nikomatsakis]

Some more details and differences from today:

• &mut T should be Freeze, I believe, since &&mut T doesn't permit mutations.
• Similarly, closures and procs can be freeze, since they should not be callable from a & reference.

[alexcrichton]

I believe that to remain sound we will have to simultaneously change the Freeze definition and add the Share bound (Freeze will no longer be sound for Arc)

[bill-myers]

Maybe we should have both a shallow Freeze and a deep Freeze?

A deep Freeze trait is essential if one wants to have enforced pure functions (along with a way to dynamically disable TLS and global state).

Also, maybe HashMap should require keys to be deeply Freeze, since otherwise their hash might change unexpectedly (theoretically, another kind might be best here, but Freeze should work in practice).

But OTOH a shallow Freeze is useful for optimization and allowing to place data in read-only memory.

[thestinger]

If you're not allowed to hide internal mutation as an implementation detail, then reference counting isn't the only thing you're unable to do. You can't use memory allocation at all. There's no working around the fact that free needs to mutate memory. There needs to be a clear definition of what is meant by this kind of immutability rather than just how it relates to reachability.

[zkamsler]

@thestinger @nikomatsakis's proposed definition (or my interpretation thereof) is fairly narrow. T can be Freeze iff the memory directly pointed at by &T cannot be changed. It is shallow and does not imply any logical immutability as the current definition might (although I am not entirely clear on the specifics of that). As such, the Freeze bound probably wouldn't be used in many places other than those that have already been enumerated.

[thestinger]

What's a use case of Freeze then? After Share lands, the only use case I can think of is type-based alias analysis and it won't want this change of definition. The current definition isn't about a logical immutability - it's about shallow immutability.

Deep immutability seems almost meaningless, as I/O and memory allocation break the invariant. The concept does not exist in GCC or LLVM. It doesn't seem useful for enforcing purity, because the methods would already need to be marked as pure or they might be performing I/O without a handle from the object.

[zkamsler]

I think the major one was the initialization of static variables, and the aforementioned optimizations.
#11781 (comment)

[nikomatsakis]

Today we decided to kill Freeze and instead rely on an Unsafe<T> type. Closing as dup of #12577.