-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Make functional programming not so inconvenient #13765
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
Comments
+1 I'm very interested in his library, partially because of some behaviors I don't like in Rust's iterators, for instance:
I'd expect it to print |
The old behaviour was fundamentally wrong by allowing use-after free: fn main() {
let mut x = ~1;
let f = || { x = ~2; &*x };
let g = &f;
let reference = (*g)();
(*g)();
println!("{}", *reference);
} prints inconsistent nonsensical values (like 28980112) with an older compiler. Will be fixed by generalised closure types #8622 (see also http://www.reddit.com/r/rust/comments/23zdlb/why_did_you_change_closures_to_be_only_usable/ ). (The solution will almost certainly just be some traits and some sugar along the lines of what you have there.) Closing as a dupe of #8622. |
…3765) We realized when running `clippy --fix` on rustdoc (PR comment [here](https://github.com/rust-lang/rust/pull/133537/files#r1861377721)) that some comments were removed, which is problematic. This PR checks that comments outside of `match` arms are taken into account before emitting the lint. changelog: Fix `single_match` lint being emitted when it should not
The latest Rust nightly build removed the ability to call closures from immutable references. This breaks my library and forces me to replace closures with trait objects that expose methods that are morally
operator()
s like:Normally, I can work around the changes introduced in every nightly build. However, this particular change significantly reduces the usability of my library, because it forces the programmer to use C++-style function objects, and by this time we should already know how "convenient" that is. My primary motivation for making rust-stl is to show that it is possible, with the right type system, to eat one's cake and have it too, to combine the elegance of Haskell/ML-style functional programming with the efficiency of C++. I want Rust to be the language that helps me make this case, and for the most part it has worked beautifully, but this time it did not.
Please do something about it.
The text was updated successfully, but these errors were encountered: