• Start Date: 2014-08-08
• RFC PR: rust-lang/rfcs#246
• Rust Issue: rust-lang/rust#17718

Summary

Divide global declarations

• constants
  定数
  declare
  宣言する
  constant
  定数
  values. These represent a value, not a memory address. This is the most common thing one would reach for and would replace static
  静的な
  as we know it today in almost all cases.
• statics
  静的な
  declare
  宣言する
  global variables
  変数、ストレージ
  . These represent a memory address. They would be rarely used: the primary
  主要な、初等の、第一の
  use cases are global locks, global atomic counters, and interfacing with legacy C libraries.

Motivation

We have been wrestling with the best way to represent globals for some times. There are a number of interrelated issues:

• Significant addresses and inlining: For optimization purposes, it is useful to be able to inline constant
  定数
  values directly
  直接
  into the program. It is even more useful if those constant
  定数
  values do not have known addresses, because that means the compiler is free to replicate them as it wishes. Moreover,
  その上
  if a constant
  定数
  is inlined into downstream crates, then they must be recompiled whenever that constant
  定数
  changes.
• Read-only memory: Whenever possible, we'd like to place large constants
  定数
  into read-only memory. But this means that the data must be truly immutable,
  不変の
  or else a segfault will result.
  結果、戻り値
• Global atomic counters and the like: We'd like to make it possible for people to create global locks or atomic counters that can be used without resorting to unsafe code.
• Interfacing with C code: Some C libraries require the use of global, mutable data. Other times it's just convenient and threading is not a concern.
• Initializer constants:
  定数
  There must be a way to have initializer constants
  定数
  for things like locks and atomic counters, so that people can write static
  静的な
  MY_COUNTER: AtomicUint = INIT_ZERO or some such. It should not be possible to modify these initializer constants.
  定数

The current design

Some concrete

• There is no way to have a safe global counter or lock. Those must be placed in static
  静的な
  mut variables,
  変数、ストレージ
  which means that access to them is illegal.
  文法違反
  To resolve
  解決する
  this, there is an alternative
  代わりのもの、選択肢
  proposal, according
  according to 〜に応じて
  to which, access to static
  静的な
  mut is considered
  みなす、考慮する
  safe if the type of the static
  静的な
  mut meets the Sync trait.
• The significance (no pun intended) of the #[inline(never)] annotation is not intuitive.
• There is no way to have a generic type constant.
  定数

Other less practical and more aesthetic concerns are:

• Although static
  静的な
  and let look and feel analogous, the two behave quite differently. Generally speaking, static
  静的な
  declarations
  宣言
  do not declare
  宣言する
  variables
  変数、ストレージ
  but rather values, which can be inlined and which do not have fixed addresses. You cannot have interior mutability in a static
  静的な
  variable,
  変数、ストレージ
  but you can in a let. So that static
  静的な
  variables
  変数、ストレージ
  can appear
  現れる
  in patterns, it is illegal
  文法違反
  to shadow a static
  静的な
  variable
  変数、ストレージ
  -- but let variables
  変数、ストレージ
  cannot appear
  現れる
  in patterns. Etc.
• There are other constructs
  作る、構成体
  in the language,
  言語
  such as nullary enum variants and nullary structs,
  構造、構造体
  which look like global data but in fact act
  振る舞う
  quite differently. They are actual
  実際の
  values which do not have addresses. They are categorized as rvalues and so forth.

Detailed design

設計（する）

Constants

定数

Reintroduce a const declaration

const name: type = value;

Constants

Possible extension: Generic constants

定数

As a possible extension, it is perfectly reasonable for constants

struct WrappedOption<T> { value: Option<T> }
const NONE<T> = WrappedOption { value: None }

Note that this makes no sense for a static

Possible extension: constant

定数

functions

It is possible to imagine constant

struct LockedData<T:Send> { lock: Lock, value: T }

const LOCKED<T:Send>(t: T) -> LockedData<T> {
    LockedData { lock: INIT_LOCK, value: t }
}

This would allow

Static

静的な

variables

変数、ストレージ

Repurpose the static

Non-mut statics

mut statics

Globals referencing Globals

const => const

It is possible to create a const or a static

struct SomeStruct { x: uint }
const FOO: SomeStruct = SomeStruct { x: 1 };
const BAR: &'static SomeStruct = &FOO;

Constants

struct SomeStruct { x: uint }
const FOO: SomeStruct = SomeStruct { x: 1 };
const BAR: &'static SomeStruct = {
    static TMP: SomeStruct = FOO;
    &TMP
};

Here a static

const => static

静的な

It is illegal

static

静的な

=> const

If a static

static

静的な

=> static

静的な

It is illegal

If a by-value reference

1. It's an initializer pattern. This is the purpose of const, however.
2. The values are kept in sync. This is currently technically infeasible.

Instead of falling into one of these two categories, the compiler will instead disallow

Patterns

Today, a static

Drawbacks

This RFC introduces two keywords for global data. Global data is kind of an edge feature so this feels like overkill. (On the other hand, the only keyword that most Rust programmers should need to know is const -- I imagine static

Alternatives

The other design

One serious concern is with regard to timing. Adding

Unresolved questions

• Should the compiler be allowed

  許可する、可能にする
  to inline the values of static
  静的な
  variables
  変数、ストレージ
  which are deeply immutable
  不変の
  (and thus
  それゆえに、従って、
  force recompilation)?

• Should we permit

  許す
  static
  静的な
  variables
  変数、ストレージ
  whose type is not Sync, but simply make access to them unsafe?

• Should we permit

  許す
  static
  静的な
  variables
  変数、ストレージ
  whose type is not Sync, but whose initializer value does not actually contain
  含む
  interior mutability? For example, a static
  静的な
  of Option<UnsafeCell<uint>> with the initializer of None is in theory safe.

• How hard are the envisioned extensions to implement? If easy, they would be nice to have. If hard, they can wait.