WG21 Paper n3030 Rvalue Reference as "Funny" Lvalues を Background だけ訳した（主に私が理解するため）

そのうち江添さんがきっちりとしたエントリーにするだろうけど、折角途中まで訳したし、背景だけ終わらせて置いときます（一部訳せなかったけど）。間違いとか飛躍しすぎとかがあればコメントなりtwitterなりで教えていただけると、私のえーぶんどっかいりょくこーじょーにもなるのでとてもありがたいです。

I. Background
Rvalue references were introduced into C++0x to provide a mechanism for capturing an rvalue temporary (which could previously be done in C++ using traditional lvalue references to const) and allowing modification of its value (which could not). When used in the contexts of reference binding, overload resolution, and template argument deduction, it was desired that a function returning an rvalue reference should behave like a traditional function returning an rvalue. The most straightforward way of achieving that goal was to classify such rvalue reference return values as rvalues, and that approach is embodied in the current draft.

I.背景
rvalue referenceは、rvalue temporaryを捕捉し（これは従来でもconstな値へのlvalue referenceを用いてできた）、それに対して変更できるようにする仕組みとして導入された（これは従来できなかった）。関数のrvalue reference返しは、referenceの束縛・オーバーロード解決・テンプレート引数の推論（template argument deduction）の文脈で用いた際、従来的な関数のrvalue返しのように振る舞うべき、ということが望まれる。この目標を達成するための最も直接的な方法は、このrvalue referenceである戻り値を、rvalueとして分類することであった。そしてこのアプローチは現在のドラフトに取り込まれている。

Unfortunately, however, rvalues have certain characteristics that are incompatible with the intended uses for rvalue references. In particular:

Rvalues are anonymous and can be copied at will, with the copy assumed to be equivalent to the original. Rvalue references, however, designate a specific object in memory (even if it is a temporary), and that identity must be maintained.
The type of an rvalue is fully known – that is, its type must be complete, and its static type is the same as its dynamic type. By contrast, an rvalue reference must support polymorphic behavior and should be able to have an incomplete type.
The type of a non-class rvalue is never cv-qualified. An rvalue reference, however, can be bound to a const or volatile object, and that qualification must be preserved.

だが、rvalueは、rvalue referenceの用途と非互換な特徴を持つ。具体的には、

rvalueは名前を持たず、コピーしたオブジェクトはオリジナルと同値であるという仮定で自由にコピーできる。しかしrvalue referenceは、それが一時オブジェクトである場合でも、特定のオブジェクトを指して、ずっと保持し続けなければならない。
rvalueの型は完全に知られている。言いかえると、rvalueの型はcompleteでなければならず、rvalueの静的な型は、動的なそれと同じである。対照的に、rvalue referenceはpolymorphicな振る舞いをサポートする必要があり、incomplete typeを持つことを認めるべきである。
classでないrvalueの型は決してcv修飾されない。しかしrvalue referenceの場合、constやvolatileなobjectへと束縛することが可能で、その修飾は保存される。

In addition, rvalue references (like traditional lvalue references) can be bound to functions. Treating an rvalue reference return value as an rvalue, however, introduces the novel concept of a function rvalue into the language. There was previously no such idea – a function lvalue used in an rvalue context becomes a pointer-to-function rvalue, not a function rvalue – so the current draft Standard does not describe how such rvalues are to be treated. In particular, function calls and conversions to function pointers are specified in terms of function lvalues, so most plausible uses of rvalue references to functions are undefined in the current wording.

さらにrvalue referenceは、（従来のlvalue referenceのように）関数へと束縛できる。しかし、rvalue referenceである戻り値をrvalueとして扱うのは、関数のrvalueについての、妙な概念を言語に持ちこむ。このようなideaは以前存在しなかった―関数のlvalueはrvalueの文脈で関数へのポインタのrvalueとなる（関数のrvalueではない）―そして、現在のドラフトは、このようなrvalueの扱われ方について述べていない。具体的に、関数呼び出しと関数ポインタへの変換は、関数のlvalueでの話で、つまり関数へのrvalue referenceついてのそれらしき使い方は、現在の文言では定義されていない。

One possible approach to resolving these problems would be to maintain the current approach of treating an rvalue reference return value as an rvalue but to add various caveats to the specification of rvalues so that those coming from rvalue references would have special characteristics. This could be called the “funny rvalue” approach. However, further examination of the current wording of the draft Standard indicates that the problems listed above are probably only the tip of the iceberg: many of the specifications that should apply to the objects to which rvalue references refer, such as object lifetime, aliasing rules, etc., are phrased in terms of lvalues, so the list of rvalue caveats could get quite long.

ここまでで述べた方法では、rvalue referenceである戻り値のrvalue扱いについて現在のアプローチを保ちたいのだが、rvalueの仕様に対して、rvalue referenceに由来するいくつかの特例を付け加えるために、特殊な特徴を持つだろう。これは "funny rvalue" アプローチと呼ぼう。しかし、現在のドラフトをより深く調べると、前述の問題は氷山の一角に過ぎないことが分かった：rvalue referenceが参照するオブジェクトへと適用すべき多くの仕様、例えばオブジェクトのlifetimeやaliasing ruleその他は、lvalueの話として記述されている。つまりrvalueに対する特例の一覧はとても長くなった。

This suggests an alternative approach: that rvalue reference return values should actually be seen as lvalues, with a few exceptions to allow them to be treated as rvalues in the cases where that is intended, i.e., in reference binding, overload resolution, and template argument deduction. This idea, dubbed the “funny lvalue” approach, is the subject of this paper.
(The problems described above are discussed in more detail in the following issues in the Core Language Issues List: 664, 690, 846, and 863.)

この提案は、対照的なアプローチを取る：rvalue referenceである戻り値は、意図したケース（referenceの束縛・オーバーロード解決・テンプレート引数の推論）においてrvalueとして扱われることを認めるためにいくつかの例外を除いて、本当にlvalueと見なすべきだ。この考え方、 "funny lvalue" と呼ばれているアプローチは、このペーパーの主題である。
（上記で述べた問題については、Core Language Issues 664, 690, 846, 863で話題になっている）