Fundamental concept clustering

[dabrahams]

I think Movable should refine Deinitializable.
I can't think of a use case for separating them and Movable + Deinitializable seems like a very common combination.
And if we don't believe that one, at least Copyable should refine Deinitializable.

We should also think hard about whether Equatable should be part of Copyable.

At this early stage, when there's plenty of time to change our minds, the default should be to cluster as much as possible.

[dabrahams]

Here's another thing to consider. Copyable + Deinitializable implies assignability. Today we could write:

trait Assignable: Copyable, Deinitializable {
  fun become_equal(to source: Self) inout { deinit(); self = source.copy() }
}

With optimizations for “I already have the storage, don't deallocate it” on specific types. Of course we could also add

conformance<T: Copyable & Deinitializable> T: Assignable {}

but this is getting really complicated and has negative implications for dispatch under static selection.

A much simpler world:

trait Copyable: Movable /* implying Deinitializable */ {
  fun copy() -> Self
  fun become_equal(to source: Self) inout { deinit(); self = source.copy() }
}

[kyouko-taiga]

I am absolutely, utterly convinced we need Movable without Deinitializable. We need the ability to create indestructible objects whose ownership can move in and out of functions. That is necessary for capabilities and other sort of parts that can be fractioned before being re-merged again.