pantsbuild #development

Channels

welcome

github-notifications

development

witty-crayon-22786

10/27/2017, 7:42 PM

cc @enough-analyst-54434 since you'll run into these

witty-crayon-22786

10/27/2017, 7:43 PM

the

[closure@...]

bit contains the meat of the issue: the closure is essentially a codegen'd struct, and that line describes what the captured fields are

witty-crayon-22786

10/27/2017, 7:44 PM

and this one captures references... which would be totally fine in some contexts, but Futures bound the lifetime of their closures to

'static

witty-crayon-22786

10/27/2017, 7:51 PM

...which means that the closure could contain references, but only references with the static lifetime

witty-crayon-22786

10/27/2017, 7:52 PM

in this case... probably Arc, since the data is variable length and copying it would be a bummer?

average-vr-56795

10/30/2017, 2:49 PM

Thanks, that's really helpful! (Though also, frustrating that the compiler starts hiding closures :S)

average-vr-56795

10/30/2017, 2:50 PM

I feel like I'm probably holding Arc wrong; I appear to need to manually clone() it every time I want to use it in a move scope, which is... Annoying...

average-vr-56795

10/30/2017, 2:57 PM

I'll clean up what I have and put up a PR; hopefully I'm just doing something obviously wrong 🙂

enough-analyst-54434

10/30/2017, 3:23 PM

Pretty sure clone is exactly right. That's what increments the reference count.

witty-crayon-22786

10/30/2017, 5:12 PM

@average-vr-56795: yea, clone is correct

witty-crayon-22786

10/30/2017, 5:13 PM

the choice to make

Arc

Clone

Copy

is an interesting one

witty-crayon-22786

10/30/2017, 5:13 PM

Copy

is implicit... ie, the compiler will do it automatically

witty-crayon-22786

10/30/2017, 5:13 PM

...oh, hm... i don't think you can implement

Copy

if you have any logic involved with clone

witty-crayon-22786

10/30/2017, 5:14 PM

Copy

memcpy

witty-crayon-22786

10/30/2017, 5:14 PM

so the explicit clone is necessary (as it stands) to implement the reference counting

average-vr-56795

10/30/2017, 5:15 PM

Yeah. I'll put up that PR soon - I think my real complaint is less with how often I need to clone, and more with how often I need to make an alias variable to allow the thing to actually move

witty-crayon-22786

10/30/2017, 5:15 PM

yea.

witty-crayon-22786

10/30/2017, 5:16 PM

well... it's not an alias probably... it's a copy

witty-crayon-22786

10/30/2017, 5:16 PM

but yea, with you.

average-vr-56795

10/30/2017, 5:18 PM

Separate track: Any tips for writing a block which returns either a Join or an error?

witty-crayon-22786

10/30/2017, 5:18 PM

...boxing =/

average-vr-56795

10/30/2017, 5:18 PM

I'm in an futures and_then, and if I just unwrap all of my errors life is good, and I can't quite work out what I should be returning to return an error

witty-crayon-22786

10/30/2017, 5:19 PM

Box<Future<_, _>>

should unify the type

average-vr-56795

10/30/2017, 5:20 PM

Should my error be an Err, a futures:futureerr, or something else?

witty-crayon-22786

10/30/2017, 5:21 PM

the latter

witty-crayon-22786

10/30/2017, 5:21 PM

both branches of the block result in Future instances

average-vr-56795

10/30/2017, 5:22 PM

Yeah, that's what I thought, but then it complains to me that expected struct

futures::FutureResult

, found struct

futures::Join

and a Join is a Future instance

witty-crayon-22786

10/30/2017, 5:22 PM

but they will have different sizes/shapes, thus need boxing. and unfortunately, the initial version of

impl Trait

will not help with things on the stack, afaik.

witty-crayon-22786

10/30/2017, 5:22 PM

@average-vr-56795: boxing

average-vr-56795

10/30/2017, 5:23 PM

I tried .to_boxed() on them both and still no joy; I'll try Box::new() around them