Dear Emil Dotchevski,

     Thank you for your inquiry. Regarding your questions...

- Is it possible for out_ptr to support returning the shared_ptr instead of taking it as an argument?

     That's not the purpose of this library. This library is to interoperate with pre-existing functions whose interfaces you don't have control of or that can't be brought into the wonderful world of C++: if you had control, you could just -- as you have done with your code -- write a wrapper. The problem is that writing wrappers continually does not scale, and it is very hard to automate that kind of boilerplate until we get the Reflection TS / Static Reflection in C++. This library does not aim to try to write a whole new Boost.Preprocessor based, orfunction-signature-reflection-and-conversion library. That is a massive undertaking, and far beyond the scope of this library.

- Is it possible to support non-pointer handle types as well?

     It already supports non-pointer handle types, because you can specify the pointer type explicitly. We have examples for out_ptr<void*>, but nothing is stopping you from doing out_ptr<int>. I frequently use this in C Style APIs which work with integers. Here is an example of using `int` representing a "file descriptor" with unique_ptr: https://github.com/ThePhD/out_ptr/blob/master/examples/source/std.custom_unique_ptr.cpp#L112

    out_ptr and inout_ptr work out-of-the-box with custom handle types and unique_resource, for example. The following example has a specialization only because it wants to gain the special performance-enhancing properties: but the interface of the handle class in the example is perfectly adequate on its own without the written customization point: https://github.com/ThePhD/out_ptr/blob/master/examples/source/custom.handle.cpp#L82

- Can error handling be incorporated? I realize there are different options, but perhaps only two need to be supported: a result<T> of some sort (such types' interfaces are somewhat standard much like smart pointer interfaces are) or throw an exception.
 
     Since it works with the typical C-style of pointer output parameters, no. If somebody worked on some new, cool library doing some of what I outlined in the answer to your first question: maybe!

Sincerely,
JeanHeyd Meneide