Non-ideal ergonomics for `*ChildWrapper`s?

[TheLostLambda]

Thanks for all of your help and pointers so far — I'm close to getting things fully working, but I've found it a little cumbersome to create an StdChildWrapper that doesn't overwrite all of the methods of things like JobObjectWrapper.

My wrapper looks like this:

#[derive(Debug)]
struct LogFileChild {
    inner: Box<dyn StdChildWrapper>,
    thread: Option<JoinHandle<io::Result<u64>>>,
}

And the solution is to (I believe) manually implement all of the default methods that either of my other wrappers (JobObject or CreationFlags) use, and change the default implementation from something like self.inner_mut().kill() to self.inner.kill(). This is obviously non-ideal, because:

1. I need to dig into the source-code of process-wrap to figure out which methods I need to manually implement / change from self.inner_mut() to self.inner, something of a SemVer nightmare (unless I just manually implement every single method).
2. It, I believe, introduces more order-dependent behavior — if I put my wrapper before JobObject, for example, then any changes I make to a method that JobObjectChild doesn't re-implement / forward would be lost. If I wrote something for id() or stdout(), it would be completely and silently discarded.

I think that, conceptually, what's needed is to change the Child in the return types of inner(), inner_mut(), and into_inner() into something like Box<dyn StdChildWrapper> — that way, by default, all of the unimplemented methods would retain the previous wrappers! If this is something you think is a fundamentally good idea, then I'm happy to brainstorm about the implementation (e.g. should this really be a Box<dyn...>, or should it be a generic trait, or one with an associated type, etc).

Currently, I believe, any new ChildWrapper with any methods left default is wiping the effects of all of the previous wrappers, and that feels like a pretty major footgun that makes it challenging to build new wrapper combinations, but I love this library so much that I'd love to help fix that!

[passcod]

Oh yes, I see what you mean. If A implements kill() but B doesn't, then wrapping B(A) uses the default kill(), not A's kill(). That's undesirable.

I think the main issue I can see is that it becomes harder to obtain the raw child if you need to, but I'm not sure it's a very useful feature in the first place.

I think Box would be idiomatic to the rest of the library, that feels fine.

[TheLostLambda]

If we're going with Boxes (which I agree might be most consistent here), then maybe we can still have a way to get a Child by upcasting to Any then downcasting? It's not something I've really done before, but the last example in this section looks super promising: https://blog.rust-lang.org/2025/04/03/Rust-1.86.0/#trait-upcasting

Personally I've not needed that raw child, but if we do want to keep that functionality, then I think that could be a solution?

[passcod]

The library itself needs the raw child in the job_object implemetation, e.g. when I implement the change I eventually get to:

    Checking process-wrap v8.2.1 (/home/passcod/code/rust/process-wrap)
error[E0599]: no method named `raw_handle` found for reference `&dyn TokioChildWrapper` in the current scope
  --> src/tokio/job_object.rs:82:6
   |
80 | /             inner
81 | |                 .inner()
82 | |                 .raw_handle()
   | |                 -^^^^^^^^^^ method not found in `&dyn TokioChildWrapper`
   | |_________________|
   |

For more information about this error, try `rustc --explain E0599`.
error: could not compile `process-wrap` (lib) due to 1 previous error

[TheLostLambda]

Another option could be adding a raw_child() set of methods that default to self.inner().raw_child() or something like that?

[passcod]

Okay I've got an experimental implementation at #23. Could you give that a try with your usecase?

[passcod]

Ah, I've just noticed you use the std feature. I'll see if I can quickly replicate the changes over Done

[TheLostLambda]

Very exciting! I'll check this out tomorrow and let you know!