Summary

Just like structs,

構造、構造体
variants can come in three forms
形式、形態、形作る
 - unit-like, tuple-like, or struct-like:


#![allow(unused)]
fn main() {
enum Foo {
    Foo,
    Bar(int, String),
    Baz { a: int, b: String }
}
}

The last form

形式、形態、形作る
is currently feature gated. This RFC proposes to remove that gate before 1.0.

Motivation

Tuple

タプル(複合型)
variants with multiple
複数の
 fields can become difficult to work with, especially when the types of the fields don't make it obvious what each one is. It is not an uncommon sight in the compiler to see inline comments used to help identify
同定する、特定する
 the various
さまざまな
 variants of an enum, such as this snippet
断片
 from rustc::middle::def:


#![allow(unused)]
fn main() {
pub enum Def {
    // ...
    DefVariant(ast::DefId /* enum */, ast::DefId /* variant */, bool /* is_structure */),
    DefTy(ast::DefId, bool /* is_enum */),
    // ...
}
}

If these were changed to struct

構造、構造体
variants, this ad-hoc documentation
文書
 would move into the names of the fields themselves. These names are visible in rustdoc, so a developer doesn't have to go source
元の
 diving to figure out what's going on. In addition,
追加
 the fields of struct
構造、構造体
 variants can have documentation
文書
 attached.


#![allow(unused)]
fn main() {
pub enum Def {
    // ...
    DefVariant {
        enum_did: ast::DefId,
        variant_did: ast::DefId,
        /// Identifies the variant as tuple-like or struct-like
        is_structure: bool,
    },
    DefTy {
        did: ast::DefId,
        is_enum: bool,
    },
    // ...
}
}

As the number of fields in a variant increases,

増加する、昇順の
it becomes increasingly crucial to use struct
構造、構造体
 variants. For example, consider
考える、みなす
 this snippet
断片
 from rust-postgres:


#![allow(unused)]
fn main() {
enum FrontendMessage<'a> {
    // ...
    Bind {
        pub portal: &'a str,
        pub statement: &'a str,
        pub formats: &'a [i16],
        pub values: &'a [Option<Vec<u8>>],
        pub result_formats: &'a [i16]
    },
    // ...
}
}

If we convert

変換する
Bind to a tuple
タプル(複合型)
 variant:


#![allow(unused)]
fn main() {
enum FrontendMessage<'a> {
    // ...
    Bind(&'a str, &'a str, &'a [i16], &'a [Option<Vec<u8>>], &'a [i16]),
    // ...
}
}

we run into both the documentation

文書
issues discussed above, as well as ergonomic issues. If code only cares about the values and formats fields, working with a struct
構造、構造体
 variant is nicer:


#![allow(unused)]
fn main() {
match msg {
    // you can reorder too!
    Bind { values, formats, .. } => ...
    // ...
}
}

versus


#![allow(unused)]
fn main() {
match msg {
    Bind(_, _, formats, values, _) => ...
    // ...
}
}

This feature gate was originally put in place because there were many serious bugs in the compiler's support for struct

構造、構造体
variants. This is not the case today. The issue tracker does not appear
現れる
 have any open correctness issues related to struct
構造、構造体
 variants and many libraries, including rustc itself, have been using them without trouble for a while.

Detailed design
設計（する）

Change the Status of the struct_variant feature from Active to Accepted.

The fields of struct

構造、構造体
variants use the same style of privacy as normal struct
構造、構造体
 fields - they're private unless tagged pub. This is inconsistent with tuple
タプル(複合型)
 variants, where the fields have inherited
継承する
 visibility. Struct
構造、構造体
 variant fields will be changed to have inhereted privacy, and pub will no longer be allowed.
許可する、可能にする

Drawbacks

Adding

たす
formal support for a feature increases
増加する、昇順の
 the maintenance burden of rustc.

Alternatives
代わりのもの、選択肢

If struct

構造、構造体
variants remain feature gated at 1.0, libraries that want to ensure
保証する
 that they will continue working into the future will be forced to avoid
避ける、回避する
 struct
構造、構造体
 variants since there are no guarantees
保証する
 about backwards compatibility
互換性
 of feature-gated parts of the language.
言語

Unresolved questions

N/A