Skip to content

Commit da29bd4

Browse files
committed
Squashed commit of the following:
commit 50642be8dfabc072431a5e7a450d39a27711f5a1 Author: Ken Kawamoto <kentaro.kawamoto@gmail.com> Date: Sat May 6 10:07:23 2017 -0700 chapter 3.5
1 parent 3281292 commit da29bd4

File tree

2 files changed

+37
-1
lines changed

2 files changed

+37
-1
lines changed

src/SUMMARY.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@
1414
* [生存期間](lifetimes.md)
1515
* [生存期間システムの限界](lifetime-mismatch.md)
1616
* [生存期間の省略](lifetime-elision.md)
17-
* [Unbounded Lifetimes](unbounded-lifetimes.md)
17+
* [無制限のライフタイム](unbounded-lifetimes.md)
1818
* [Higher-Rank Trait Bounds](hrtb.md)
1919
* [Subtyping and Variance](subtyping.md)
2020
* [Drop Check](dropck.md)

src/unbounded-lifetimes.md

Lines changed: 36 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,10 @@
1+
<!--
12
# Unbounded Lifetimes
3+
-->
24

5+
# 無制限のライフタイム
6+
7+
<!--
38
Unsafe code can often end up producing references or lifetimes out of thin air.
49
Such lifetimes come into the world as *unbounded*. The most common source of this
510
is dereferencing a raw pointer, which produces a reference with an unbounded lifetime.
@@ -8,29 +13,60 @@ than simply becoming `'static`, because for instance `&'static &'a T`
813
will fail to typecheck, but the unbound lifetime will perfectly mold into
914
`&'a &'a T` as needed. However for most intents and purposes, such an unbounded
1015
lifetime can be regarded as `'static`.
16+
-->
17+
18+
アンセーフなコードはときに、リファレンスやライフタイムを何も無いところから生み出したりします。
19+
そのようなライフタイムは、*無制限* なライフタイムとして世界に登場します。
20+
最もよくあるのは、生のポインタのデリファンレンスし、無制限のライフタイムを持つ参照を作り出すというケースです。
21+
このライフタイムは、そのコンテキストが必要とするだけ大きくなります。そしてこれは `'static` よりも強力なしくみです。
22+
`&'static &'a T` は型チェックをパスしませんが、無制限のライフタイムを使うと必要に応じて `&'a &'a T` となるからです。
23+
しかし、ほとんどの意図と目的においては、無制限のライフタイムを `'static` と解釈できます。
1124

25+
<!--
1226
Almost no reference is `'static`, so this is probably wrong. `transmute` and
1327
`transmute_copy` are the two other primary offenders. One should endeavor to
1428
bound an unbounded lifetime as quickly as possible, especially across function
1529
boundaries.
30+
-->
31+
32+
参照が `'static` であることはまずありえないので、これはおそらく間違っていると言えるでしょう。
33+
おもに `transmute``transmute_copy` とがこの状況を作り出します。
34+
できるだけ速く、とくに関数の境界では、無制限のライフタイムに制限をつけるように気をつけて下さい。
1635

36+
<!--
1737
Given a function, any output lifetimes that don't derive from inputs are
1838
unbounded. For instance:
39+
-->
40+
41+
関数の入力から導出されない出力のライフタイムは無制限となります。例えば、
1942

2043
```rust,ignore
2144
fn get_str<'a>() -> &'a str;
2245
```
2346

47+
<!--
2448
will produce an `&str` with an unbounded lifetime. The easiest way to avoid
2549
unbounded lifetimes is to use lifetime elision at the function boundary.
2650
If an output lifetime is elided, then it *must* be bounded by an input lifetime.
2751
Of course it might be bounded by the *wrong* lifetime, but this will usually
2852
just cause a compiler error, rather than allow memory safety to be trivially
2953
violated.
54+
-->
55+
56+
このコードは無制限のライフタイムを持った `&str` を生成します。
57+
無制限のライフタイムを避ける最も簡単な方法は、関数境界でライフタイムを省略することです。
58+
出力ライフタイムが省略された場合、入力ライフタイムで制限されなくては*いけません*
59+
もちろん、*間違った*ライフタイムで制限されるかもしれませんが、たいていの場合は、メモリ安全性が侵されるのではなく、コンパイルエラーにつながります。
3060

61+
<!--
3162
Within a function, bounding lifetimes is more error-prone. The safest and easiest
3263
way to bound a lifetime is to return it from a function with a bound lifetime.
3364
However if this is unacceptable, the reference can be placed in a location with
3465
a specific lifetime. Unfortunately it's impossible to name all lifetimes involved
3566
in a function.
67+
-->
3668

69+
関数内部でライフタイムを制限することは、エラーを生みやすくなります。
70+
ライフタイムを制限する安全で簡単な方法は、制限つきライフタイムの関数から返される値を使うことです。
71+
しかし、これができない場合は、そのリファレンスを特定のライフタイムがついた場所に置くと良いでしょう。
72+
残念ながら、関数内のすべてのライフタイムに名前をつけるのは不可能です。

0 commit comments

Comments
 (0)