> The way I handled it at first with the "binding magic" was this:
> 1. check if the pointer is null
> 2a. Yes -> push Lua's nil with `lua_pushnil(L)` (what sol::nil represents in C++ land)
> 2b. No -> push userdata
So I did misunderstood things a bit, but now I think I get the picture.
I'd say there are two questions for you to answer:
Q1. What should I do if the user wants to pop a smart pointer, but the value is incompatible? E.g., a number where a shared_ptr is expected? I am not a user of your library, so I just do not know. An exception that bubbles up as a Lua error would not be unreasonable here.
Q2. Do I need to handle the special nil case differently from the general case #1?
#2 can be considered independently of #1. Inside your library pop code, you know that it might be nil, because that is how it is pushed in case 2a. You can therefore construct an empty smart pointer (or, if your code is more generic than this, default-construct an object) and give it to the user code. Perhaps you can just construct it on stack, because, if the user code changes that object, it will probably be impossible for you to inject it into where the nil came from.
