Skip to content

Associated consts from traits not always resolved in match patterns #25017

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.

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

Closed
quantheory opened this issue May 1, 2015 · 1 comment
Closed
Labels
A-associated-items Area: Associated items (types, constants & functions)

Comments

@quantheory
Copy link
Contributor

Note that the following addition to the associated-const-match-patterns test would fail:

assert!(match Bar::Var1 {
    Foo::THEBAR => true,
    _ => false,
});

However, the existing test uses <Foo>::THEBAR and passes, even though the two syntaxes should be equivalent. There is no particularly deep issue here, I just seem to have been misunderstanding UFCS on the day when I wrote the resolve code involved, and as a result only inherent impls are picked up unless you use angle brackets. I plan to have a PR to fix this and a few other easy issues this weekend.

For future reference, this should be the case for associated constants:

Type::CONST // Equivalent to `<Type>::CONST`
<Type>::CONST // Resolves to `CONST` in an inherent impl if there is one, else a trait impl if not ambiguous.
Trait::CONST // Meaningless; there is absolutely no way to resolve this.
<Trait>::CONST // Currently meaningless, but may be useful if we add constants to the vtable for  trait objects in the future.
<Type as Trait>::CONST // Resolves to the particular impl of `Trait for Type`.
@steveklabnik steveklabnik added the A-associated-items Area: Associated items (types, constants & functions) label May 2, 2015
bors added a commit that referenced this issue May 14, 2015
…age, r=nikomatsakis

This fixes #24922 and #25017, and reduces the number of error messages that talk about "methods" when associated constants rather than methods are involved.

I will admit that I haven't thought very carefully about the error messages. My goal has been to make more of the messages technically correct in all situations, and to avoid ICEs. But in some cases we could probably talk specifically about "methods" rather than "items".
@quantheory
Copy link
Contributor Author

Closing due to merge of #25065.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-associated-items Area: Associated items (types, constants & functions)
Projects
None yet
Development

No branches or pull requests

2 participants