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

Jump to bottom

Allow parameter types to be omitted from closure expressions #2093

Closed
nikomatsakis opened this issue Apr 1, 2012 · 6 comments
Closed

Allow parameter types to be omitted from closure expressions #2093

nikomatsakis opened this issue Apr 1, 2012 · 6 comments
Labels
A-grammar Area: The grammar of Rust A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@nikomatsakis
Copy link
Contributor

We should allow you to write fn&(x, y) and infer the types for x and y just as we now infer the types for {|x, y|...}. Similarly we should infer the return type too---not sure whether we should require something like fn&(x, y) -> { ... } in that case, though.
@brson
Copy link
Contributor

brson commented Apr 1, 2012

I think this makes sense. Do we yet allow type annotations on block lambdas? If we did that then are both forms of anonymous function the same except that one can't ret and the other can't be used in for expressions?

@nikomatsakis
Copy link
Contributor Author

We do allow type annotations in sugared closures. I believe the two forms are basically equivalent but for ret, for, and of course the fact that sugar closures infer the protocol (fn@ vs fn&), for better or worse.

Ah, there is one other difference: you can have capture clauses on fn@ and friends, but not on a sugared closure.

I was going to propose changing the syntax to amend that distinction, but I forgot about it. I'll make a second issue for that.

@catamorphism
Copy link
Contributor

Added the RFC label since this seems like a change requiring consensus.

@nikomatsakis nikomatsakis mentioned this issue Apr 12, 2012
Closed
@nikomatsakis nikomatsakis reopened this May 4, 2012
@pnkfelix
Copy link
Member

  1. Its not clear to me why Niko re-opened this issue after he put in 1ba4ca4
  2. To my knowledge we have removed [**] the [<sigil>] fn (<id>, ...) { <body> ... } value-expression syntax (there is still a [<sigil>] fn(<type> ...) -> <type> type-expression syntax, but that is not relevant here).
  3. Anyway, my point is, this bug seems like it can be closed, since the syntactic form which which it is concerned no longer exists. (Unless I have grossly misunderstood the situation, but all my experiments on test programs indicate that this value-expression syntax no longer exists.)

[**] I cannot find the reference for a meeting where removing the value-expression form was decided; the closest I have come to doing so is the weekly mtg from 2013-02-19, where Niko discussed allowing one to put the sigils on the front of the |<id>, ...| { <body> ...} form.

@fhahn
Copy link
Contributor

fhahn commented Feb 10, 2014

I've stumbled over an ignored test case which mentions this issue: src/test/compile-fail/omitted-arg-wrong-types.rs . The code compiles just fine with current Rust. I guess we could remove that test case or am I missing something?

@nikomatsakis
Copy link
Contributor Author

@fhahn yeah just remove the test. This issue is no longer relevant due to language drift, basically. That test now compiles fine because of integer inference.

fhahn added a commit to fhahn/rust that referenced this issue Feb 22, 2014
@fhahn
Remove some obsolete ignored tests
c9b1b70 
* compile-fail/vec-add.rs is obsolete, there are no mutable
  vectors any more, rust-lang#2711 is closed
* compile-fail/issue-1451.rs is obsolete, there are no more
  structural records, rust-lang#1451 is closed
* compile-fail/issue-2074.rs is obsolete, an up to date test
  is in run-pass/nested-enum-same-names.rs, rust-lang#2074 is closed
* compile-fail/omitted-arg-wrong-types.rs is obsolete, rust-lang#2093
  is closed
@fhahn fhahn mentioned this issue Feb 22, 2014
Closed
alexcrichton pushed a commit to alexcrichton/rust that referenced this issue Feb 25, 2014
@fhahn @alexcrichton
Remove some obsolete ignored tests
3ca0167 
* compile-fail/vec-add.rs is obsolete, there are no mutable
  vectors any more, rust-lang#2711 is closed
* compile-fail/issue-1451.rs is obsolete, there are no more
  structural records, rust-lang#1451 is closed
* compile-fail/issue-2074.rs is obsolete, an up to date test
  is in run-pass/nested-enum-same-names.rs, rust-lang#2074 is closed
* compile-fail/omitted-arg-wrong-types.rs is obsolete, rust-lang#2093
  is closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-grammar Area: The grammar of Rust A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@brson @nikomatsakis @pnkfelix @catamorphism @fhahn