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.

[pnkfelix]

(also, this bug may be more of an RFC than a bug ... its really hard to tell from the description what is actionable here, or the suggested course of action, if anything...)

[pnkfelix]

(removing P-backcompat-libs since it is not a 1.0 blocker.)

Also, to whom it may concern: please do not tag issues with the P-tags; nominated them for consideration via I-nominated.

[emberian]

Such a tool is the subject of #9060

On Thu, Feb 13, 2014 at 1:25 PM, Felix S Klock II
notifications@github.comwrote:

(removing P-backcompat-libs since it is not a 1.0 blocker.)

Also, to whom it may concern: please do not tag issues with the P-tags;
nominated them for consideration via I-nominated.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12202#issuecomment-35008989
.

[aturon]

Closing: there doesn't seem to be anything actionable here, especially given the issue #12203

[emberian]

I agree.

On Tue, Jun 10, 2014 at 10:51 AM, Aaron Turon notifications@github.com
wrote:

Closed #12202 #12202.

—
Reply to this email directly or view it on GitHub
#12202 (comment).

http://octayn.net/