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

RFC: Remove bind #2189

Closed
nikomatsakis opened this issue Apr 12, 2012 · 8 comments
Closed

RFC: Remove bind #2189

nikomatsakis opened this issue Apr 12, 2012 · 8 comments
Assignees

Comments

@nikomatsakis
Copy link
Contributor

I think it's time for bind to go. My reasons:

  • The language will have that many fewer keywords and syntactic constructs.
  • The semantics are incompatible with closures. Right now, if I write foo(_, f()) this evaluates f() right away and binds the result into the closure. This is quite different from {|x| foo(x, f())} which is surprising. This has led to bugs.
  • The type system is complex enough. Bind is a weird corner case we tend to forget about. We already found one such problem (move mode arguments) and I am confident there are more lurking. Let's simplify our lives and only think about closures, which are hard enough.

As a side effect of this change, naming a method like a.b without calling it will presumably become an error.

@graydon
Copy link
Contributor

graydon commented Apr 12, 2012

Agree.

@brson
Copy link
Contributor

brson commented Apr 12, 2012

I agree, though I do like the syntax of bind better. Maybe in the future we can add something syntactically similar as an extension.

@nikomatsakis
Copy link
Contributor Author

FWIW, I still like the change I proposed a while back where expressions
with "_" were converted into closures. The main objection was that the
extent of the created closure could be confusing (with which I am
sympathetic). I'd be in favor of a similar extension that addressed
this issue, whatever it is.

@catamorphism
Copy link
Contributor

I agree. I do think bind syntax is occasionally convenient -- like currying in Haskell, except the captured arguments don't have to be a prefix of the non-captured arguments, so it's more flexible -- but I don't think that necessarily justifies the complexity and potential confusion.

@catamorphism
Copy link
Contributor

Do we have consensus? Any objections from @pcwalton or @marijnh ?

@marijnh
Copy link
Contributor

marijnh commented Apr 20, 2012

I'd like to see classical bind removed and Niko's old proposal for desugaring calls containing _ holes to closures.

@ghost ghost assigned brson Jun 18, 2012
brson added a commit to brson/rust that referenced this issue Jun 21, 2012
@brson
Copy link
Contributor

brson commented Jun 29, 2012

@Lenny222. Not yet. The value of methods can still be taken, so there is some bind machinery still there.

@msullivan
Copy link
Contributor

I have a patch to get rid of our code that depends on taking the values of methods and a patch that rips out the rest of the bind code. Still need to reject taking values of methods in the typechecker...

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
run Clippy on CI

and fix some things it complains about. Also use `rustup-toolchain` script on CI (reduces code duplication, and good thing to make sure it keeps working, since we recommend it in the docs).

I left `ui_test` out for now; I'll leave those nits to `@oli-obk.` ;)
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants