Summary

Allow

許可する、可能にする
constraints
制約
 to appear
現れる
 in where clauses
句、節
 which are trivially known to either always hold
保有する、有効である
 or never hold.
保有する、有効である
 This would mean that impl Foo for Bar where i32: Iterator would become valid,
有効な、正しい
 and the impl would never be satisfied.
満たす、満足させる

Motivation

It may seem strange to ever want to include a constraint

制約
that is always known to hold
保有する、有効である
 or not hold.
保有する、有効である
 However, as with many of these cases, allowing
許可する、可能にする
 this would be useful for macros. For example, a custom derive
派生する
 may want to add additional
追加の
 functionality if two derives are used together. As another more concrete
具体的な/具象的な
 example, Diesel allows
許可する、可能にする
 the use of normal Rust operators
演算子
 to generate the equivalent
等価
 SQL. Due to coherence rules, we can't actually provide a blanket impl, but we'd like to automatically
自動的に
 implement
実装する
 std::ops::Add for columns when they are of a type for which + is a valid
有効な、正しい
 operator.
演算子
 The generated impl would look like:


#![allow(unused)]
fn main() {
impl<T> std::ops::Add<T> for my_column
where
    my_column::SqlType: diesel::types::ops::Add,
    T: AsExpression<<my_column::SqlType as diesel::types::ops::Add>::Rhs>,
{
    // ...
}
}

One would never write this impl normally since we always know the type of my_column::SqlType. However, when you consider

みなす、考慮する
the use case of a macro, we can't always easily know whether that constraint
制約
 would hold
保有する、有効である
 or not at the time when we're generating
生成する
 code.

Detailed design
設計（する）

Concretely implementing

実装する
this means the removal of E0193. Interestingly, as of Rust 1.7, that error never actually appears.
現れる
 Instead the current behavior
ふるまい
 is that something like impl Foo for Bar where i32: Copy (e.g. anywhere
どこでも
 that the constraint
制約
 always holds) compiles fine, and impl Foo for Bar where i32: Iterator fails to compile by complaining that i32 does not implement
実装する
 Iterator. The original error message explicitly
明示的に
 forbidding this case does not seem to ever appear.
現れる

The obvious complication that comes to mind when implementing

実装する
this feature is that it would allow
許可する、可能にする
 nonsensical projections to appear
現れる
 in the where clause
句、節
 as well. For example, when i32: IntoIterator appears
現れる
 in a where clause,
句、節
 we would also need to allow
許可する、可能にする
 i32::Item: SomeTrait to appear
現れる
 in the same clause,
句、節
 and even allow
許可する、可能にする
 for _ in 1 to appear
現れる
 in item bodies, and have it all successfully compile.

Since code that was caught by this error is usually nonsense outside of macros, it would be valuable for the error to continue to live on as a lint. The lint trivial_constraints would be added,

たす
matching
一致する、マッチさせる
 the pre-1.7 semantics of E0193, and would be set
セットする、集合
 to warn by default.

How We Teach This

This feature does not need to be taught explicitly.

明示的に
Knowing the basic rules of where clauses,
句、節
 one would naturally already expect this to work.

Drawbacks

  • The changes to the compiler could potentially increase complexity quite a bit

Alternatives

n/a

Unresolved questions

Should the lint error by default instead of warn?