Check all types for well-formedness with respect to the bounds制限する、結び付けられて
of type variables.変数、ストレージ
Allow許可する、可能にする
bounds制限する、結び付けられて
on formal type variable変数、ストレージ
in structs構造、構造体
and enums. Check these bounds制限する、結び付けられて
are satisfied満たす、満足させる
wherever the struct構造、構造体
or enum is used with actual実際の
type parameters.仮引数
Makes type checking saner. Catches errors earlier in the development開発
process. Matches behaviour with built-in組み込みの
bounds制限する、結び付けられて
(I think).
Currently formal type variables変数、ストレージ
in traits and functions may have bounds制限する、結び付けられて
and these bounds制限する、結び付けられて
are checked whenever the item is used against the actual実際の
type variables.変数、ストレージ
Where these type variables変数、ストレージ
are used in types, these types should be checked for well-formedness with respect to the type definitions.定義
E.g.,
trait U {}
trait T<X: U> {}
trait S<Y> {
fn m(x: ~T<Y>) {} // Should be flagged as an error
}
Formal type variables変数、ストレージ
in structs構造、構造体
and enums may not have bounds.制限する、結び付けられて
It is possible to use these type variables変数、ストレージ
in the types of fields, and these types cannot be checked for well-formedness until the struct構造、構造体
is instantiated, where each field must be checked.
struct St<X> {
f: ~T<X>, // Cannot be checked
}
Likewise, impls of structs構造、構造体
are not checked. E.g.,
impl<X> St<X> { // Cannot be checked
...
}
Here, no struct構造、構造体
can exist where X is replaced by something implementing U, so in the impl, X can be assumed to have the bound制限する、結び付けられて
U. But the impl does not indicate指し示す
this. Note, this is sound, but does not indicate指し示す
programmer intent very well.
Whenever a type is used it must be checked for well-formedness. For polymorphic types we currently check only that the type exists. I would like to also check that any actual実際の
type parameters仮引数
are valid.有効な、正しい
That is, given与えられた
a type T<U> where T is declared宣言
as T<X: B>, we currently only check that T does in fact exist somewhere (I think we also check that the correct number of type parameters仮引数
are supplied, in this case one). I would also like to check that U satisfies満たす、満足させる
the bound制限する、結び付けられて
B.
Work on built-in組み込みの
bounds制限する、結び付けられて
is (I think) in the process of addingたす
this behaviour for built-in組み込みの
bounds.制限する、結び付けられて
I would like to apply適用する
this to user-specified bounds制限する、結び付けられて
too.
I think no fewer programs can be expressed. That is, any errors we catch with this new check would have been caught later in the existing scheme, where exactly正確に
would depend on where the type was used. The only exception例外
would be if the formal type variable変数、ストレージ
was not used.
We would allow許可する、可能にする
bounds制限する、結び付けられて
on type variable変数、ストレージ
in structs構造、構造体
and enums. Wherever a concrete具体的な/具象的な
struct構造、構造体
or enum type appears,現れる
check the actual実際の
type variables変数、ストレージ
against the bounds制限する、結び付けられて
on the formals (the type well-formedness check).
From the above examples:
trait U {}
trait T<X: U> {}
trait S1<Y> {
fn m(x: ~T<Y>) {} //~ ERROR
}
trait S2<Y: U> {
fn m(x: ~T<Y>) {}
}
struct St<X: U> {
f: ~T<X>,
}
impl<X: U> St<X> {
...
}
Keep the status quo.
We could add bounds制限する、結び付けられて
on structs,構造、構造体
etc. But not check them in impls. This is safe since the implementation実装
is more general一般
than the struct.構造、構造体
It would mean we allow許可する、可能にする
impls to be un-necessarily general.一般
Do we allow許可する、可能にする
and check bounds制限する、結び付けられて
in type aliases? We currently do not. We should probably continue not to since these type variables変数、ストレージ
(and indeed the type aliases) are substituted away early in the type checking process. So if we think of type aliases別名
as almost macro-like, then not checking makes sense. OTOH, it is still a little bit inconsistent.