Skip to content

E0122: clarify wording #43176

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 11, 2017
Merged

E0122: clarify wording #43176

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ba53f95
E0122: clarify wording
RalfJung Jul 12, 2017
5067ef2
fix line lengths
RalfJung Jul 12, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions src/librustc_typeck/diagnostics.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1611,9 +1611,9 @@ static BAR: _ = "test"; // error, explicitly write out the type instead
"##,

E0122: r##"
An attempt was made to add a generic constraint to a type alias. While Rust will
allow this with a warning, it will not currently enforce the constraint.
Consider the example below:
An attempt was made to add a generic constraint to a type alias. This constraint
is entirely ignored. For backwards compatibility, Rust still allows this with a
warning. Consider the example below:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is incorrect. The constraint is required to use associated type syntax (without writing <T as Trait>::Assoc - which you can't for Fn traits on stable).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you elaborate? Are you saying there is a difference between the constraint being "not enforced" and "entirely ignored"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the constraint is only ignored when referencing the alias, not within it. Actually I think <T as Trait>::Assoc still requires a T: Trait bound. And the only reason that works is we effectively recover a T: Trait bound from the presence of a <T as Trait>::Assoc type, even if we don't know whether the type came from somewhere which already required T: Trait.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the constraint is only ignored when referencing the alias, not within it.

Are you sure?

This is accepted:

struct Test<T: Copy> { t : T}

type MyTest<T> = Test<T>;

And so it this:

trait Test {
    type Type;
}

type MyTest<T> = <T as Test>::Type;

To me it looks like constraints are not at all checked or enforced inside aliases.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nikomatsakis Do we not do any WF-checking in type aliases?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eddyb at present, I think we do not! I expect we are going to make various changes here -- possibly in a "new epoch", but hopefully we can pull it off without that.


```
trait Foo{}
Expand Down