Skip to content
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

Document that associated constants prevent a trait from being made into an object #48026

Merged
merged 1 commit into from
Feb 6, 2018

Conversation

Badel2
Copy link
Contributor

@Badel2 Badel2 commented Feb 6, 2018

Fixes #47952

Add a short mention of associated constants to E0038

@rust-highfive
Copy link
Collaborator

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

@Badel2
Copy link
Contributor Author

Badel2 commented Feb 6, 2018

I would love to add why exactly they are not allowed, but I couldn't find the reason. Relevant issues: #29646 #26847

@Badel2 Badel2 force-pushed the doc-assoc-const-object-safe branch from 1a3239b to 78ea7ee Compare February 6, 2018 01:50
@Havvy
Copy link
Contributor

Havvy commented Feb 6, 2018

The reason is that because the trait object implements the trait too, and what would the constant be for that trait object? E.g. given a trait Trait with an associated constant CONST of type i32, what would this mean?

fn takes_trait_obj(t: &dyn Trait) -> i32 { <dyn Trait>::CONST }

Or as another (I think it was @eddyb?) said on IRC, a constant is effectively a no-argument static (const) function, and static functions aren't allowed for the same reason.

@eddyb
Copy link
Member

eddyb commented Feb 6, 2018

r? @nikomatsakis

@rust-highfive rust-highfive assigned nikomatsakis and unassigned eddyb Feb 6, 2018
@pietroalbini pietroalbini added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 6, 2018
@nikomatsakis
Copy link
Contributor

@Badel2 did @Havvy's explanation make sense to you? Would you like to try updating to include more background on why it is not allowed?

@Badel2
Copy link
Contributor Author

Badel2 commented Feb 6, 2018

The explaination makes sense, especially when compared to static functions. It's a shame you can't add where Self: Sized to constants. I will move this error just below the static functions one, and add "Just like static functions, associated constants aren't stored on the method table".

@Badel2 Badel2 force-pushed the doc-assoc-const-object-safe branch from 78ea7ee to 498ef20 Compare February 6, 2018 17:45
@nikomatsakis
Copy link
Contributor

@Badel2 once the GAT work is fully done, we can probably support that, actually (where Self: Sized)

@nikomatsakis
Copy link
Contributor

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Feb 6, 2018

📌 Commit 498ef20 has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 6, 2018
@eddyb
Copy link
Member

eddyb commented Feb 6, 2018

Wait, why does where Self: Sized not work? Is it just syntactical? I'd fully expect to (I don't see GAT would be relevant - even if we supported generic constants, they're like generic methods, not GAT).

kennytm added a commit to kennytm/rust that referenced this pull request Feb 6, 2018
… r=nikomatsakis

Document that associated constants prevent a trait from being made into an object

Fixes rust-lang#47952

Add a short mention of associated constants to E0038
bors added a commit that referenced this pull request Feb 6, 2018
Rollup of 7 pull requests

- Successful merges: #46962, #47986, #48012, #48013, #48026, #48031, #48036
- Failed merges:
@bors bors merged commit 498ef20 into rust-lang:master Feb 6, 2018
@nikomatsakis
Copy link
Contributor

@eddyb it's not particularly dependent on GAT per se, but right now we don't have a notion of "where clauses that must be satisfied in order to project" -- I expect to be adding that as part of GAT, in which case it would apply here.

Note the sort of subtle distinction between:

trait Foo {
    type Bar: Baz;
}

This is a constraint on the impl that it supply a type that is Baz. Versus:

trait Foo {
    type Bar where Self: Sized;
}

This is a constraint on the one doing the projection that Self: Sized must hold for them to do it.

@eddyb
Copy link
Member

eddyb commented Feb 7, 2018

@nikomatsakis We have them on methods and we check them when referring to those methods.
There is no real difference between "projecting a const" and "projecting an fn" here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants