You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In RFC 1023, we introduced the idea of fundamental traits. The primary motivation here, if I recall, was that there were some APIs which wished to take either a closure or a concrete value. Therefore, the #[fundamental] annotation was added to the Fn traits -- and I think no others? (We should check.) This attribute allowed coherence to "cheat" with respect to the closure traits and determine that they were not implemented.
We may be stuck with this mechanism forever, since there can definitely be user-space code that relies on. But we also may not: we could potentially remove #[fundamental] traits and introduce instead explicit negative impls for the other legal values that can be supplied to such functions.
Details
We should try removing fundamental, introducing the appropriate negative impls, and doing a crater run!
The text was updated successfully, but these errors were encountered:
Motivation
In RFC 1023, we introduced the idea of fundamental traits. The primary motivation here, if I recall, was that there were some APIs which wished to take either a closure or a concrete value. Therefore, the
#[fundamental]
annotation was added to theFn
traits -- and I think no others? (We should check.) This attribute allowed coherence to "cheat" with respect to the closure traits and determine that they were not implemented.We may be stuck with this mechanism forever, since there can definitely be user-space code that relies on. But we also may not: we could potentially remove
#[fundamental]
traits and introduce instead explicit negative impls for the other legal values that can be supplied to such functions.Details
We should try removing fundamental, introducing the appropriate negative impls, and doing a crater run!
The text was updated successfully, but these errors were encountered: