uv_loop_t escape hatch?

[abrownsword]

Could an escape hatch be added to the Loop class that simply returns the internal uv_loop_t handle? I find myself having to add an accessor to get at it so that I can call any unwrapped functions (there are a couple still) or pass it to another libuv-based library.

[skypjack]

so that I can call any unwrapped functions (there are a couple still)

Can I ask what are the unwrapped functions?
It would be good to fill the gap if possible.

Could an escape hatch be added to the Loop class

Wouldn't it make much sense to add that escape hatch also to handles, requests and all the other classes that wrap a struct defined by libuv instead?

[abrownsword]

I haven’t done a complete inventory, but the two in my code are debug functions that dump the active handles.

I suggested uv_loop_t alone because that is the level at which I would expect to interact with a libuv-enabled library. Sharing handles and such seems more fraught with challenges.

[skypjack]

I haven’t done a complete inventory

Don't worry, I didn't expect it. Just curious.

Sharing handles and such seems more fraught with challenges.

I think uvw side it's a matter of a few lines of code actually. I'm having a try during the day.

What about adding an operator uv_loop_t *() in your case?
You can do something like this then:

auto loop = uvw::Loop::getDefault();
// Get the pointer directly
uv_loop_t *uloop = *loop;
// Pass the underlying loop to a function that expects uv_loop_t *
uv_loop_init(*loop);

[abrownsword]

Not my library, so its up to you. If you’re asking how, in my opinion, this ought to look then I would strongly favour NOT using a conversion operator, and require the user who needs to do this exceptional thing to call a named member function. Preferably something that makes it crystal clear what is going on. Perhaps loop->get_internal_uv_type() or something. In general we don’t want these internal libuv data types to leak out, so when they are made available the code should be easy to spot and easy to search for. And I think the uv_loop_t is the safest one because the lifetime management issues are minimal — with connection handles and the like, they come and go more often so trying to share them with other code is much more likely to cause bugs around their lifetime.

[skypjack]

Yeah, I was asking for your opinion.
I like to discuss new features of an open source library with real users. They bring points of views out of their experiences that usually help a lot.

What you said makes sense actually. I'm trying to find the best name, preferably a bit shorter then get_internal_uv_type. :-)

And I think the uv_loop_t is the safest one because the lifetime management issues are minimal

Well, if you are going to work raw you must know exactly what you are doing after all. Otherwise you cannot avoid subtle bugs. A library can't help you in any case with this.
On the other side, making available also underlying types for handles and requests would allow users to use new functionalities shipped with libuv and not yet wrapped by uvw.