Skip to content

lambdas and blocks should both have optional type decls #1275

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 Dec 9, 2011 · 5 comments
Closed

lambdas and blocks should both have optional type decls #1275

nikomatsakis opened this issue Dec 9, 2011 · 5 comments
Assignees
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-type-system Area: Type system

Comments

@nikomatsakis
Copy link
Contributor

Right now, lambdas must declare types for their arguments and blocks must not. But both are represented in more-or-less the same way and seem to go through a similar inference path in typeck.rs; I think we ought to make parameter types optional in both cases. Naturally, if the lambda/block is not used in an argument position, or at least being assigned to a variable of known type, we will not be able to infer a type for the arguments and so an error would occur.

@ghost ghost assigned marijnh Dec 9, 2011
marijnh added a commit that referenced this issue Dec 9, 2011
I.e. {|foo: int| -> int foo + 2}

Issue #1275
@marijnh
Copy link
Contributor

marijnh commented Dec 9, 2011

I took a stab at making types optional for other function expressions, but I just don't understand the type checker well enough to get that to behave.

@nikomatsakis
Copy link
Contributor Author

I am looking in this area. I may give it a go but I am going to get sendable functions working first.

@ghost ghost assigned nikomatsakis Apr 12, 2012
@catamorphism
Copy link
Contributor

@nikomatsakis - Is this obsolete? I don't seem to recall either one requiring type decls recently...

@nikomatsakis
Copy link
Contributor Author

Not yet obsolete, but I think I may have opened a second bug on this issue at some point.

@nikomatsakis
Copy link
Contributor Author

Closing in favor of #2093, which is more precise.

bjorn3 added a commit to bjorn3/rust that referenced this issue Oct 23, 2022
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
…lding from source (rust-lang#1275)

Co-authored-by: Ted Kaminski <[email protected]>
Co-authored-by: Adrian Palacios <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

3 participants