Tracking issue for RFC #2056: Allow trivial constraints to appear in where clauses (feature(trivial_bounds))

This is a tracking issue for the RFC "Allow trivial constraints to appear in where clauses " (rust-lang/rfcs#2056).

Steps:

Implement the RFC – Implement RFC 2056 trivial constraints in where clauses #48557
- As noted in Tracking issue for RFC #2056: Allow trivial constraints to appear in where clauses (feature(trivial_bounds)) #48214 (comment), the new trait solver might solve a few issues with this feature, so this is currently blocked on the new trait solver (-Znext-solver)
Adjust documentation (see instructions on forge)
Stabilization PR (see instructions on forge)

Unresolved questions:

Should the lint error by default instead of warn?

I'm working on this.

@matthewjasper

@matthewjasper ok. I've not thought hard about what it will take to support this. I had thought about doing it after making some more progress on general trait refactoring, but if it can be easily supported today seems fine.

Oh, I meant to add, please ping me on IRC/gitter with any questions! I can try to carve out some time to think about it as well.

Auto merge of #48557 - matthewjasper:allow-trvial-bounds, r=nikomatsakis

Auto merge of #50782 - matthewjasper:wheres-main, r=matthewjasper

Auto merge of #51042 - matthewjasper:reenable-trivial-bounds, r=nikom…

So with #51042 merged this feature is implemented on nightly, but the implementation isn't particularly clean and there are some edge cases that don't work as one would expect:

#![feature(trivial_bounds)]

struct A;
trait X<T> {
    fn test(&self, t: T) {}
}

impl X<i32> for A {}

fn foo(a: A) where A: X<i64> {
    a.test(1i64); // expected i32, found i64
}

Since Chalk might be able to fix some of these issues, I think that this feature is now waiting for Chalk to be integrated.

edit: As of 2018-12-28 -Zchalk does not currently solve this issue.

As another concrete example where trivially false constraints arise due to macros, see taiki-e/pin-project#102 (comment). That crate now carries a weird hack to work around this limitation.

What is the current status of this feature?

Not much has changed since my last comment.

The current implementation generates a warning when using the pre-existing impl trait syntax, which, reading the RFC, I assume is a false-positive.

#![allow(dead_code, unused_variables,)]
#![feature(trait_alias, trivial_bounds)]

trait T = Fn(&i32, &i32) -> bool;
fn impl_trait_fn() -> impl T {
	|a: &i32, b: &i32| true
}

This code generates the warning warning: Trait bound impl T: T does not depend on any type or lifetime parameters. (playground link)

Maybe this has been obvious to others, but it wasn't to me! The trivial_bounds feature gate and warning are actually only needed in cases where the bound includes no type or lifetime parameters. One can imitate the same behavior by simply adding a type or lifetime parameter to the bound artificially.

Wow this was definitely not obvious to me. For all where clause bounds that don't contain any lifetimes it looks like you should be able to emulate this 1:1 by inserting a higher-rank trait bound:

trait Trivial { }

impl Trivial for u8 where String: Copy {} // fails
impl Trivial for u8 where for<'a> String: Copy {} // works fine. Trait just not impld

Edit: Seems like this has been realized already actually haha: #48214 (comment)

I just realised that the for<'a> trick (which I've also used myself) is in effect an accidental stabilisation – writing for<'a> on stable gives you the same effect as writing #![feature(trivial_bounds)] on nightly (including the bugs). The compiler also points people who attempt it to use the feature without the feature gate to this issue, which means that quite a lot of people may have discovered the workaround by now (and it's probably also possible to figure it out on your own without looking at the bug report – I have vague memories of experimenting with that the first time I ran into this problem).

Is that something that needs attention? (On the other hand, is that a reason to just stabilise this anyway, despite the bugs? Having the feature gate doesn't seem useful given that there's a way around it.)

conditionally require Clone:

[3/n] [daft-derive] attempt to better annotate semantic errors

is that a reason to just stabilise this anyway, despite the bugs?

What are the bugs, exactly?

@Darksonn

@Darksonn: the main one I'm thinking about is #128682: although it's a bit unclear what's going on there (it doesn't have a MCVE), it appears to have constructed a situation where the typesystem thinks a trait is implemented but it actually isn't (leading to a linking failure).

That said, that bug currently isn't well-understood-enough to be certain that it's a bug in trivial_bounds rather than somewhere else.

The feature gating of this seems to not be working on structs. See #152872

I hope I am not out of place contributing here, but I wanted to flag that some (e.g., me 😄) might be using the fact that trivial constraints are not allowed as a feature, not a limitation!

For example, say I need to derive an Encode trait for a struct like

struct MyStruct<A, B, C> {
    a: A,
    b: Something<B>,
    c: Something<SomethingElse<[C; 16]>>,
    d: String
}

that has several fields, only some of which depend on the generic parameters. To implement Encode, all fields must implement Encode. What I usually derive is:

impl<A, B, C> Encode for MyStruct<A, B, C>
where
    A: Encode,
    Something<B>: Encode,
    Something<SomethingElse<[C; 16]>>,
    String: Encode,
{
    // ...
}

Now, this is perfect:

For all field types that contain a generic parameter, the where clause simply restricts which generics Encode gets implemented for;
For all field types that don't contain a generic parameter (e.g., String in MyStruct), the type not implementing Encode is a hard error.

I know in principle the correct thing to do would be to traverse every field type to determine whether or not a generic parameter appears anywhere inside it, but taking the lazy route has always worked for me, at least until I noticed this issue. If trivial constraints were allowed in where clauses, all of a sudden my code (and that of every lazy deriver like me) would behave unexpectedly:

Deriving Encode on a concrete struct whose fields do not implement Encode would compile just fine..
.. but Encode simply would not be implemented.

As an aside: yes, I did figure out the for<'dummy> trick as well! I suspect many might be using it do differentiate between "I want this trivial where to cause an error if not satisfied" and "I simply want the trait not to be implemented, don't throw an error".

It seems entirely reasonable to have a lint against unsatisfiable bounds. But forbidding them entirely is not a great state IMO.

Rollup merge of rust-lang#153034 - arferreira:fix-trivial-bound-diagn…

Unrolled build for #153034

Navigation Menu

Repository navigation

Tracking issue for RFC #2056: Allow trivial constraints to appear in where clauses (`feature(trivial_bounds)`) #48214

37 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for RFC #2056: Allow trivial constraints to appear in where clauses (feature(trivial_bounds)) #48214

Description

Activity

matthewjasper commented on Feb 18, 2018

nikomatsakis commented on Feb 19, 2018

nikomatsakis commented on Feb 19, 2018

matthewjasper commented on Jun 10, 2018

RalfJung commented on Oct 13, 2019

matthewjasper commented on Oct 13, 2019

Systemcluster commented on Nov 14, 2019

37 remaining items

stegaBOB commented on Apr 13, 2025

ais523 commented on Oct 9, 2025

Darksonn commented on Feb 9, 2026

ais523 commented on Feb 10, 2026

theemathas commented on Feb 20, 2026

matteomonti commented on Feb 23, 2026

RalfJung commented on Feb 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for RFC #2056: Allow trivial constraints to appear in where clauses (`feature(trivial_bounds)`) #48214