@@ -20,6 +20,8 @@ that syntax is expanded during
20
20
[ "type collection"] ( ./type-checking.html ) into the explicit form,
21
21
though that is something we may want to change in the future.)
22
22
23
+ [ intoiter-item ] : https://doc.rust-lang.org/nightly/core/iter/trait.IntoIterator.html#associatedtype.Item
24
+
23
25
<a name =normalize >
24
26
25
27
In some cases, associated type projections can be ** normalized** --
@@ -51,8 +53,8 @@ we saw above would be lowered to a program clause like so:
51
53
52
54
forall<T> {
53
55
Normalize(<Option<T> as IntoIterator>::Item -> T)
54
- }
55
-
56
+ }
57
+
56
58
(An aside: since we do not permit quantification over traits, this is
57
59
really more like a family of predicates, one for each associated
58
60
type.)
@@ -98,7 +100,7 @@ We now introduce the `ProjectionEq` predicate to bring those two cases
98
100
together. The ` ProjectionEq ` predicate looks like so:
99
101
100
102
ProjectionEq(<T as IntoIterator>::Item = U)
101
-
103
+
102
104
and we will see that it can be proven * either* via normalization or
103
105
skolemization. As part of lowering an associated type declaration from
104
106
some trait, we create two program clauses for ` ProjectionEq ` :
@@ -123,7 +125,7 @@ with unification. As described in the
123
125
basically a procedure with a signature like this:
124
126
125
127
Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution>
126
-
128
+
127
129
In other words, we try to unify two things A and B. That procedure
128
130
might just fail, in which case we get back ` Err(NoSolution) ` . This
129
131
would happen, for example, if we tried to unify ` u32 ` and ` i32 ` .
0 commit comments