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

Is automatic insertion of type inference placeholders possible? #43942

Open
mqudsi opened this issue Aug 17, 2017 · 1 comment
Open

Is automatic insertion of type inference placeholders possible? #43942

mqudsi opened this issue Aug 17, 2017 · 1 comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@mqudsi
Copy link
Contributor

mqudsi commented Aug 17, 2017

Would it be possible to automatically insert _ type inference placeholders where none (or not enough) type placeholders are provided, or does this conflict with any other tokens the parser has to deal with?

i.e. can ["foo", "bar"].iter().collect::Vec::() be turned into ["foo", "bar"].iter().collect::Vec<_>::() automatically?

and given a Struct<X,Y>, can Struct<Foo> automatically be understood as Struct<Foo, _>?

These would both simplify boilerplate considerably, and the latter could obviate the need to revisit old code when a type is expanded with an additional generic type parameter that can be inferred from its usage.

@petrochenkov
Copy link
Contributor

It is possible, but there was unresolved issues about how exactly to infer the missing types in presence of default type parameters, so _s are required so far to be future-compatible with any possible solution.
The relevant issue is #27336, but there wasn't much progress recently :(

@Mark-Simulacrum Mark-Simulacrum added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. I-needs-decision Issue: In need of a decision. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Aug 20, 2017
@Centril Centril added C-feature-request Category: A feature request, i.e: not implemented / a PR. and removed C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. I-needs-decision Issue: In need of a decision. labels Sep 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants