I should elaborate: I think you've successfully formulated placement new in
terms of unboxed closures as monomorphized traits whose "call" method takes
self by value. That is, something like (in Rust of the future):
fn GC<T,F:OnceFunc<T>>(f: F) -> GC<T>
The difference, though, is that the construction of the closure is implicit at
the call site in this proposal. This is what I'm uncomfortable with. Rust is a
strict language, not a lazy one, and the order of evaluation of function
arguments is one of the things that one has heretofore been unable to change. I
would prefer that a different argument evaluation order would necessitate some
sort of annotation at the call site (e.g. ocaml's "lazy"). But once you've done
that you've essentially recreated something equivalent to placement new, but
more verbose since you have to name a method when you allocate into an object
(e.g. instead of "box(my_arena) foo" you'd have to write "my_arena.alloc(lazy
foo)". I think we would end up wanting the sugar.
Patrick
"Gábor Lehel" <[email protected]> wrote:
>Yes, that was one of the things that passed through my mind as well.
>One
>difference is that those are passed at runtime, whereas here everything
>happens at compile time. I remember LLVM had difficulty reliably
>optimizing
>runtime closure passing code, like with the old iterators.
>
>
>On Wed, Dec 4, 2013 at 5:05 AM, Daniel Micay <[email protected]>
>wrote:
>
>> This looks a lot like what stack once functions would provide.
>>
>
>
>
>--
>Your ship was destroyed in a monadic eruption.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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
