On 01/01/14 01:43, Patrick Walton wrote:
On 12/31/13 6:09 AM, Huon Wilson wrote:
On 01/01/14 00:55, Armin Ronacher wrote:
Hi,
On 30/12/2013 17:29, Patrick Walton wrote:
This is the first time I've heard of this as a missing feature, and
I'm
opposed. This would make typechecking significantly more complex.
I'm not saying someone should add decltype :) Just that from using
the iterators we have now it becomes quite obvious that there are
missing tools to use them to the fullest extend.
The question in my mind is whether all these things that we want are
backwards compatible, not whether they're nice to have. Anything
backwards compatible that is not already in the language is probably
post-1.0 at this point. *This is not because we don't want to add new
features*—it's OK to add new features to the language. Version 1.0
doesn't mean we are done and the language is frozen for all time. It
just means we're going to stop making breaking language changes.
If we were to have unboxed closures similar to C++, where each closure
is an (implicit) unique type, we'd likely need something like decltype
(well, decltype(auto)) to make it possible to return them and things
containing them, e.g. higher-order iterators like .map and .filter.
(cc https://github.com/mozilla/rust/issues/3228 and
https://github.com/mozilla/rust/issues/10448)
Returning unboxed closures doesn't strike me as all that useful at the
moment, unless we add back capture clauses to allow values to be moved
in. Otherwise all you can refer to as upvars are passed-in parameters
(due to lifetime restrictions).
In the event that you want to return closures that move in values, I
would say just use an explicit struct and a trait for now. We can
revisit this decision backwards compatibly if we need to in the future.
Returning an iterator containing an unboxed closure that was passed in
doesn't require that feature, I don't think:
pub fn map<T,F:Fn<T>>(x: &[T], f: F) -> MapIterator<F> { ... }
I mean
fn my_pipeline<I: Iterator<T>>(x: I) ->
MapIterator<FilterIterator<I,
what_do_I_write_for_the_function_type_here>, and_again> {
x.filter(|un| boxed).map(|also| unboxed)
}
(where the function/closure is the second param to {Map,Filter}Iterator.)
Huon
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
