Skip to content

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

Closed
eduardoleon opened this issue Apr 25, 2014 · 2 comments
Closed

Make functional programming not so inconvenient #13765

eduardoleon opened this issue Apr 25, 2014 · 2 comments

Comments

@eduardoleon
Copy link

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:

pub trait CallableOnce<T, U> {
    fn only_call(self, x: T) -> U;
}

pub trait CallableManyTimes<T, U> : CallableOnce<T, U> {
    fn one_call_amongst_many(&self, x: T) -> U;
}

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.

@Denommus
Copy link
Contributor

+1

I'm very interested in his library, partially because of some behaviors I don't like in Rust's iterators, for instance:

fn main() {
    let mut foo = "abcd".chars();
    let bar = foo.by_ref().take_while(|&x| x < 'c').collect::<~str>();
    let baz = foo.collect::<~str>();
    println!("{} {}", bar, baz);
}

I'd expect it to print ab cde. Instead, it prints ab de. @eduardoleon 's library wouldn't have the same kind of problem. Despite that, it would be a very interesting alternate approach to solve the problem all by itself, and seeing Rust being capable of implementing it would just be great.

@huonw
Copy link
Member

huonw commented Apr 26, 2014

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.

@huonw huonw closed this as completed Apr 26, 2014
flip1995 pushed a commit to flip1995/rust that referenced this issue Dec 15, 2024
…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
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

3 participants