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.
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 , ast::DefId , bool ),
DefTy(ast::DefId, bool ),
}
}
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,
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 {
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.
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.許可する、可能にする
Addingたす
formal support for a feature increases増加する、昇順の
the maintenance burden of rustc.
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.言語
N/A