Fail to convert std::shared_ptr -> sol::nil -> std::shared_ptr

[noGithub-oO]

I have a C++ function, that returns std::shared_ptr (factory). From lua code I call that function, store returned value in local var and then call another C++ function, that accepts std::shared_ptr. When factory returns nullptr, it gets pushed in lua as sol::nil, but when I later try to use that native lua nil in a call, it is not converted to std::shared_ptr, but rather causes application to crash. When compiling with type checks, sol detects type mismatch and panics.
Is there any way to instruct sol to automatically convert nil into deafult-constructed std::shared_ptr when forwarding it as an argument? Anyway, it seems strange, that such thing causes total crash, and not even a normal error (which can be checked and caught).

[ThePhD]

TL;DR: this is going to take a lot of effort to figure out the proper semantics for.

The glib answer to this question is "No". That is, when we get a std::shared_ptr out of Lua using sol2, we assume that lua_touserdata works and thusly we return you a reference to the actual memory (std::shared_ptr<stuff>&). This was done so that you could manipulate the shared_ptr directly in C++ without having to force a copy. The downside is that, because we return a reference, we can't "convert" anything: either it's there or it isn't, and when sol::lua_nil is there, then the obvious answer is you can't reference memory that doesn't exist (because it's a nullptr, and not a std::shared_ptr<stuff> that happens to have nullptr inside of it).

If you took a T* for your function argument, this problem goes away because we detect null and can hand you the value of a pointer (that is to say, T* is a trivial copy and if it's nullptr we don't have to care: it doesn't have to be a reference to some existing blob of memory and it is trivially copyable so you can take is by value in your function argument). If you take a shared_ptr by value, that means that a bogus, null reference can't be pulled successfully out of Lua.

"But what if you detect when I want something by-value, and when I want something by-reference, and then do The Right Thing™ when you can?" Difficult to do, and error-prone for everyone who wants to add their own pointer-types/unique_usertypes to sol2 or otherwise. They'd need to know the two type categories and how to handle them, plus constness and all, and that's a heavy burden of implementation alongside customization burden to give to the user.

[noGithub-oO]

Ok, thank you very much for the explanation. Will use the raw-pointer-accepting API then.