Summary

Today's Show trait will be tasked with the purpose of providing

与える
the ability to inspect the representation
表現
 of implementors of the trait. A new trait, String, will be introduced to the std::fmt module to in order
順序
 to represent data that can essentially be serialized to a string, typically
一般的に、典型的に
 representing
表現する
 the precise internal state of the implementor.

The String trait will take

とる
over the {} format specifier and the Show trait will move to the now-open {:?} specifier.

Motivation

The formatting traits today largely provide clear guidance to what they are intended for. For example the Binary

２進数
trait is intended for printing the binary
２進数
 representation
表現
 of a data type. The ubiquitous Show trait, however, is not quite well defined
定義する
 in its purpose. It is currently used for a number of use cases which are typically
一般的に、典型的に
 at odds with one another.

One of the use cases of Show today is to provide a "debugging view" of a type. This provides

与える
the easy ability to print some string representation
表現
 of a type to a stream in order
順序
 to debug an application. The Show trait, however, is also used for printing user-facing information. This flavor of usage is intended for display to all users as opposed
反対する、対置する
 to just developers. Finally, the Show trait is connected to the ToString trait providing
与える
 the to_string method unconditionally.

From these use cases of Show, a number of pain points have arisen over time:

  1. It's not clear whether all types should implement
    実装する
     Show or not. Types like Path quite intentionally avoid
    避ける、回避する
     exposing a string representation
    表現
     (due to paths not being valid
    有効な、正しい
     UTF-8 always) and hence do not want a to_string method to be defined
    定義する
     on them.
  2. It is quite common to use #[deriving(Show)] to easily print a Rust structure. This is not possible, however, when particular members do not implement
    実装する
     Show (for example a Path).
  3. Some types, such as a String, desire the ability to "inspect" the representation
    表現
     as well as printing the representation.
    表現
     An inspection mode, for example, would escape characters
    文字
     like newlines.
    改行
  4. Common pieces of functionality, such as assert_eq! are tied to the Show trait which is not necessarily implemented
    実装する
     for all types.

The purpose of this RFC is to clearly define

定義する
what the Show trait is intended to be used for, as well as providing
与える
 guidelines to implementors of what implementations
実装
 should do.

Detailed Design
設計（する）

As described

記述する
in the motivation section,
節
 the intended use cases for the current Show trait are actually motivations for two separate formatting traits. One trait will be intended for all Rust types to implement
実装する
 in order
順序
 to easily allow
許可する、可能にする
 debugging values for macros such as assert_eq! or general
一般
 println! statements.
文
 A separate trait will be intended for Rust types which are faithfully represented
表現する
 as a string. These types can be represented
表現する
 as a string in a non-lossy fashion and are intended for general
一般
 consumption by more than just developers.

This RFC proposes naming these two traits Show and String, respectively.

それぞれ

The String trait

A new formatting trait will be added

たす
to std::fmt as follows:
下記の、次に続く、追従する


#![allow(unused)]
fn main() {
pub trait String for Sized? {
    fn fmt(&self, f: &mut Formatter) -> Result;
}
}

This trait is identical

同一の(である)
to all other formatting traits except for its name. The String trait will be used with the {} format specifier, typically
一般的に、典型的に
 considered
みなす、考慮する
 the default specifier for Rust.

An implementation

実装
of the String trait is an assertion
アサーション
 that the type can be faithfully represented
表現する
 as a UTF-8 string at all times. If the type can be reconstructed from a string, then it is recommended, but not required, that the following relation be true:


#![allow(unused)]
fn main() {
assert_eq!(foo, from_str(format!("{}", foo).as_slice()).unwrap());
}

If the type cannot necessarily be reconstructed from a string, then the output may be less descriptive than the type can provide, but it is guaranteed

保証する
to be human readable for all users.

It is not expected that all types implement

実装する
the String trait. Not all types can satisfy the purpose of this trait, and for example the following types will not implement
実装する
 the String trait:

  • Path will abstain as it is not guaranteed
    保証する
     to contain
    含む
     valid
    有効な、正しい
     UTF-8 data.
  • CString will abstain for the same reasons as Path.
  • RefCell will abstain as it may not be accessed at all times to be represented
    表現する
     as a String.
  • Weak references
    参照
     will abstain for the same reasons as RefCell.

Almost all types that implement

実装する
Show in the standard library today, however, will implement
実装する
 the String trait. For example all primitive integer
整数
 types, vectors, slices, strings, and containers will all implement
実装する
 the String trait. The output format will not change from what it is today (no extra escaping or debugging will occur).

The compiler will not provide an implementation

実装
of #[deriving(String)] for types.

The Show trait

The current Show trait will not change location nor definition,

定義
but it will instead move to the {:?} specifier instead of the {} specifier (which String now uses).

An implementation

実装
of the Show trait is expected for all types in Rust and provides
与える
 very few guarantees
保証する
 about the output. Output will typically
一般的に、典型的に
 represent the internal state as faithfully as possible, but it is not expected that this will always be true. The output of Show should never be used to reconstruct the object itself as it is not guaranteed
保証する
 to be possible to do so.

The purpose of the Show trait is to facilitate debugging Rust code which implies

暗黙の
that it needs to be maximally useful by extending
拡張する
 to all Rust types. All types in the standard library which do not currently implement
実装する
 Show will gain an implementation
実装
 of the Show trait including Path, RefCell, and Weak references.
参照

Many implementations

実装
of Show in the standard library will differ from what they currently are today. For example str's implementation
実装
 will escape all characters
文字
 such as newlines
改行
 and tabs in its output. Primitive integers
整数
 will print the suffix of the type after the literal in all cases. Characters
文字
 will also be printed with surrounding
囲う
 single
単一の
 quotes while escaping values such as newlines.
改行
 The purpose of these implementations
実装
 are to provide debugging views into these types.

Implementations

実装
of the Show trait are expected to never panic! and always produce
産出する
 valid
有効な、正しい
 UTF-8 data. The compiler will continue to provide a #[deriving(Show)] implementation
実装
 to facilitate printing and debugging user-defined structures.

The ToString trait

Today the ToString trait is connected to the Show trait, but this RFC proposes wiring it to the newly-proposed String trait instead. This switch enables users of to_string to rely on the same guarantees

保証する
provided
与える
 by String as well as not erroneously
誤って
 providing
与える
 the to_string method on types that are not intended to have one.

It is strongly discouraged to provide an implementation

実装
of the ToString trait and not the String trait.

Drawbacks

It is inherently easier to understand fewer concepts from the standard library and introducing multiple

複数の
traits for common formatting implementations
実装
 may lead to frequently mis-remembering which to implement.
実装する
 It is expected, however, that this will become such a common idiom in Rust that it will become second nature.

This RFC establishes a convention that Show and String produce

産出する
valid
有効な、正しい
 UTF-8 data, but no static
静的な
 guarantee
保証する
 of this requirement is provided.
与える
 Statically guaranteeing
保証する
 this invariant would likely involve adding
たす
 some form
形式、形態、形作る
 of TextWriter which we are currently not willing to stabilize for the 1.0 release.

The default format specifier, {}, will quickly become unable to print many types in Rust. Without a #[deriving] implementation,

実装
manual
マニュアル、手動
 implementations
実装
 are predicted to be fairly sparse. This means that the defacto default may become {:?} for inspecting Rust types, providing
与える
 pressure to re-shuffle the specifiers. Currently it is seen as untenable, however, for the default output format of a String to include escaped characters
文字
 (as opposed
反対する、対置する
 to printing the string). Due to the debugging nature of Show, it is seen as a non-starter to make it the "default" via {}.

It may be too ambitious to define

定義する
that String is a non-lossy representation
表現
 of a type, eventually motivating other formatting traits.

Alternatives

The names String and Show may not necessarily imply "user readable" and "debuggable". An alternative

代わりのもの、選択肢
proposal would be to use Show for user readability
可読性
 and Inspect for debugging. This alternative
代わりのもの、選択肢
 also opens up the door for other names of the debugging trait like Repr. This RFC, however, has chosen String for user readability
可読性
 to provide a clearer connection with the ToString trait as well as emphasizing that the type can be faithfully represented
表現する
 as a String. Additionally, this RFC considers
みなす、考慮する
 the name Show roughly on par with other alternatives and would help reduce churn for code migrating today.

Unresolved Questions

None at this time.