Skip to content

recursive bounds do not work (a.k.a., f-bounded polymorphism) #2355

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
nikomatsakis opened this issue May 4, 2012 · 6 comments
Closed

recursive bounds do not work (a.k.a., f-bounded polymorphism) #2355

nikomatsakis opened this issue May 4, 2012 · 6 comments
Labels
A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.

Comments

@nikomatsakis
Copy link
Contributor

The following fails:

iface foo<A> { }
fn bar(A: foo<A>) { ... }

Weird as it looks there are good use cases for this. We should support it. IIRC, the code almost does it right, or maybe even does it right, if the name resolution were patched up properly.

@ghost ghost assigned nikomatsakis May 17, 2012
@pnkfelix
Copy link
Member

pnkfelix commented May 2, 2013

@nikomatsakis So, obviously your example is using out-dated syntax, but just to be clear:

You're talking about bounds on a type-parameter, not on a value-parameter, right?

I.e. I would write your example as something like:

trait foo<A> { }

fn bar<A : foo<A> >(_x: A) { /* ... */ }

@pnkfelix
Copy link
Member

pnkfelix commented May 2, 2013

Also, the trivial form I give above compiles; so I'll try to come up with a real-world use case of f-bounded polymorphism just to double-check that this bug is still a real problem.

@nikomatsakis
Copy link
Contributor Author

it's very possible that it works now

@alexcrichton
Copy link
Member

Visiting for triage, I agree that this compiles today. It sounds like we're not sure what an example test case of this would be, so I'm going to close for now and this can be re-opened if a test case comes up. Feel free to also reopen if you think there's more to do!

@emberian
Copy link
Member

Needs a test in the suite before it should be closed.

@ghost ghost assigned pnkfelix Jul 17, 2013
@pnkfelix
Copy link
Member

reassigning to self so that I remember to make a test

pnkfelix added a commit to pnkfelix/rust that referenced this issue Sep 2, 2013
@bors bors closed this as completed in 4f151b3 Sep 3, 2013
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
This flag makes benchcomp not create a fresh copy of each benchmark directory before running each variant. The default behaviour is to make a new copy each time, to avoid built artefacts from silently being skipped, and to ensure that patches apply cleanly. Users can use this flag when benchmark runs are guaranteed to be idempotent, to avoid waiting for benchmark suites to be copied to a fresh directory.
tshepang added a commit to tshepang/rust that referenced this issue Apr 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants