1
+ <!--
1
2
# Unbounded Lifetimes
3
+ -->
2
4
5
+ # 無制限のライフタイム
6
+
7
+ <!--
3
8
Unsafe code can often end up producing references or lifetimes out of thin air.
4
9
Such lifetimes come into the world as *unbounded*. The most common source of this
5
10
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`
8
13
will fail to typecheck, but the unbound lifetime will perfectly mold into
9
14
`&'a &'a T` as needed. However for most intents and purposes, such an unbounded
10
15
lifetime can be regarded as `'static`.
16
+ -->
17
+
18
+ アンセーフなコードはときに、リファレンスやライフタイムを何も無いところから生み出したりします。
19
+ そのようなライフタイムは、* 無制限* なライフタイムとして世界に登場します。
20
+ 最もよくあるのは、生のポインタのデリファンレンスし、無制限のライフタイムを持つ参照を作り出すというケースです。
21
+ このライフタイムは、そのコンテキストが必要とするだけ大きくなります。そしてこれは ` 'static ` よりも強力なしくみです。
22
+ ` &'static &'a T ` は型チェックをパスしませんが、無制限のライフタイムを使うと必要に応じて ` &'a &'a T ` となるからです。
23
+ しかし、ほとんどの意図と目的においては、無制限のライフタイムを ` 'static ` と解釈できます。
11
24
25
+ <!--
12
26
Almost no reference is `'static`, so this is probably wrong. `transmute` and
13
27
`transmute_copy` are the two other primary offenders. One should endeavor to
14
28
bound an unbounded lifetime as quickly as possible, especially across function
15
29
boundaries.
30
+ -->
31
+
32
+ 参照が ` 'static ` であることはまずありえないので、これはおそらく間違っていると言えるでしょう。
33
+ おもに ` transmute ` と ` transmute_copy ` とがこの状況を作り出します。
34
+ できるだけ速く、とくに関数の境界では、無制限のライフタイムに制限をつけるように気をつけて下さい。
16
35
36
+ <!--
17
37
Given a function, any output lifetimes that don't derive from inputs are
18
38
unbounded. For instance:
39
+ -->
40
+
41
+ 関数の入力から導出されない出力のライフタイムは無制限となります。例えば、
19
42
20
43
``` rust,ignore
21
44
fn get_str<'a>() -> &'a str;
22
45
```
23
46
47
+ <!--
24
48
will produce an `&str` with an unbounded lifetime. The easiest way to avoid
25
49
unbounded lifetimes is to use lifetime elision at the function boundary.
26
50
If an output lifetime is elided, then it *must* be bounded by an input lifetime.
27
51
Of course it might be bounded by the *wrong* lifetime, but this will usually
28
52
just cause a compiler error, rather than allow memory safety to be trivially
29
53
violated.
54
+ -->
55
+
56
+ このコードは無制限のライフタイムを持った ` &str ` を生成します。
57
+ 無制限のライフタイムを避ける最も簡単な方法は、関数境界でライフタイムを省略することです。
58
+ 出力ライフタイムが省略された場合、入力ライフタイムで制限されなくては* いけません* 。
59
+ もちろん、* 間違った* ライフタイムで制限されるかもしれませんが、たいていの場合は、メモリ安全性が侵されるのではなく、コンパイルエラーにつながります。
30
60
61
+ <!--
31
62
Within a function, bounding lifetimes is more error-prone. The safest and easiest
32
63
way to bound a lifetime is to return it from a function with a bound lifetime.
33
64
However if this is unacceptable, the reference can be placed in a location with
34
65
a specific lifetime. Unfortunately it's impossible to name all lifetimes involved
35
66
in a function.
67
+ -->
36
68
69
+ 関数内部でライフタイムを制限することは、エラーを生みやすくなります。
70
+ ライフタイムを制限する安全で簡単な方法は、制限つきライフタイムの関数から返される値を使うことです。
71
+ しかし、これができない場合は、そのリファレンスを特定のライフタイムがついた場所に置くと良いでしょう。
72
+ 残念ながら、関数内のすべてのライフタイムに名前をつけるのは不可能です。
0 commit comments