It's also not clear to me how "&once fn" can decompose into a trait in the
future. The goal in the future is to make "fn()" a type of trait, to allow for
C++-like zero-indirection closures. The different types of functions that we
have today correspond to different "self" parameters: "|A|->B" corresponds to
"&mut self" and "proc()" corresponds to "~self". But I don't see where "&once
fn" fits in.
Perhaps the right thing is to gate "&once fn" on by-value anonymous closures. I
think once functions may be able to be made to work as function trait bounds.
But implementing "&once fn" right now seems to close off our ability to have
closures with the same efficiency as C++11 in the future, unless there's
something I'm missing.
Patrick
Patrick Walton <[email protected]> wrote:
>On 11/30/13 12:04 PM, Oren Ben-Kiki wrote:
>> Just to mention in passing - there's a related principle that
>converting
>> a block to a closure shouldn't change its semantics. This obviously
>> doesn't fully work because of return/break/continue; that said, if a
>> block without such flow control constructs is wrapped into a closure,
>> you'd expect it to just work. It doesn't, because to work it would
>have
>> to be a once-called-stack-allocated lambda, which Rust doesn't have
>(I
>> don't get the reason for that either :-)
>
>If you decompose into a lambda plus the tupled set of upvars which it's
>
>moving out of, then this respects TCP.
>
>Patrick
>
>_______________________________________________
>Rust-dev mailing list
>[email protected]
>https://mail.mozilla.org/listinfo/rust-dev
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
