Stability attributes and kinds

[emberian]

When a type is marked #[stable], no changes to it should break safe code. This also means that the set of kinds it fulfills, ignoring any potential type parameters, should never get smaller. For example, a type that is marked #[stable] that is Send should always continue to be so. If it isn't Freeze, but becomes Freeze, that is ok, because it's a completely transparent change to previous users.

(Note: if we extend the type system to include inverse bounds ("NonFreeze" etc), then adding kinds to the set of fulfilled kinds should also be disallowed)

[emberian]

Nominating for 1.0, this is required to specify the stability of an API.

[nikomatsakis]

cc me

[wycats]

Could this also be allowed as a crate attribute, and automatically apply to all public exports of that crate?

[emberian]

@wycats that's #8962

[brson]

This only matter if or when we have some tool for actually enforcing that stable APIs don't change.

[nikomatsakis]

Note: if one labels a type with the expected builtin bounds, it wouldn't
make sense to permit anything other than those builtin bounds --- not
more nor less. i.e., even if you say that something is not sendable,
people may still send it unless it is truly not sendable.

[pnkfelix]

We are not currently planning on having tooling to check/enforce stability attributes. It is currently "just" documentation. Thus this issue is not a 1.0 blocker.