Saw this on HN:
https://docs.google.com/a/octayn.net/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub
I haven't been following the recent closure discussions much, but what
Go is doing might be relevant?
___
Rust-dev mailing list
On 2013-10-02, at 08:51 , Corey Richardson wrote:
Saw this on HN:
https://docs.google.com/a/octayn.net/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub
I haven't been following the recent closure discussions much, but what
Go is doing might be relevant?
FWIW, various commenters
Thanks for the link. I don't think it's too relevant: this is
basically an implementation detail for how one chooses to attach the
data to a closure pointer. We've opted to make closure pointers two
words, one for the environment and one for the code pointer. Go seems
to be moving to a one word
On Wed, Oct 2, 2013 at 6:20 AM, Niko Matsakis n...@alum.mit.edu wrote:
Thanks for the link. I don't think it's too relevant: this is
basically an implementation detail for how one chooses to attach the
data to a closure pointer. We've opted to make closure pointers two
words, one for the
On 10/2/13 4:33 AM, Daniel Micay wrote:
It seems a global constant would be enough rather than doing an allocation.
Only for fn though, since those never get freed. For ~fn we would still
need the allocation, so you don't try to call free() on a global
constant. (We could do some address
