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

Allow parameter types to be omitted from closure expressions #2093

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

Comments

Projects
None yet
5 participants
@nikomatsakis
Contributor

nikomatsakis commented Apr 1, 2012

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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Apr 1, 2012

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Apr 1, 2012

Contributor

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.

Contributor

nikomatsakis commented Apr 1, 2012

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

This comment has been minimized.

Show comment
Hide comment
@catamorphism

catamorphism Apr 5, 2012

Contributor

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

Contributor

catamorphism commented Apr 5, 2012

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

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Apr 25, 2013

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.

Member

pnkfelix commented Apr 25, 2013

  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.

@pnkfelix pnkfelix closed this Apr 25, 2013

@fhahn

This comment has been minimized.

Show comment
Hide comment
@fhahn

fhahn Feb 10, 2014

Contributor

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?

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

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Feb 11, 2014

Contributor

@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.

Contributor

nikomatsakis commented Feb 11, 2014

@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

Remove some obsolete ignored tests
* 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

bors added a commit that referenced this issue Feb 24, 2014

auto merge of #12476 : fhahn/rust/ignored-tests-update2, r=alexcrichton
This PR removes 4 obsolete ignored test cases

* compile-fail/vec-add.rs is obsolete, there are no mutable
  vectors any more, #2711 is closed
* compile-fail/issue-1451.rs is obsolete, there are no more
  structural records, #1451 is closed
* compile-fail/issue-2074.rs is obsolete, an up to date test
  is in run-pass/nested-enum-same-names.rs, #2074 is closed
* compile-fail/omitted-arg-wrong-types.rs is obsolete, #2093
  is closed

alexcrichton added a commit to alexcrichton/rust that referenced this issue Feb 25, 2014

Remove some obsolete ignored tests
* 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

alexcrichton added a commit to alexcrichton/rust that referenced this issue Feb 25, 2014

Remove some obsolete ignored tests
* 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

jxs added a commit to jxs/rust that referenced this issue Apr 2, 2014

Remove some obsolete ignored tests
* 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