Unification of v2 and v3 to a new organization

[dmitry-t]

The versions 2 and 3 are basically compatible.
There are backward incompatible differences we should address or avoid.
@kunitoki Let's discuss the migration.

[dmitry-t]

Main things to consider:

• Modern compilers make std::function work as fast as older inheritance solutions.
• Library code simplicity is important.
• sol2 sucks: no modularity.

[kunitoki]

Which kind of migration are you referring to ?

The backwards incompatible changes you refer to are needed for additional security and speed (or when you can't use exceptions), so nothing to avoid here.

Not sure exactly what you had in mind, would you mind elaborate a bit more ?

[kunitoki]

My plans moving ahead (if they might be of interest to anyone):

• secure c++ api usage free from lua panic calls (when not reentrant from lua)
• improve error handling even more, allow more detailed contextual error descriptions
• allow interacting with c++ references which are not registered luabridge classes (already started some investigations there). Now we always assume a reference is a userdata class
• improved facilities to work with coroutines and sandboxed environments (now we always register in _G even tho i allow to register on any table in v3). Better and simpler api
• improved overload resolution using type information for every argument (not only the arity) and faster lookup of matching overloads done in c++
• allow the library to work with c++20 and make it interoperable with 20 features (ranges, span, ...)
• more to come

[kunitoki]

What about if we create a luabridge organization and move there ? @dmitry-t

[kunitoki]

This is why LuaBridge3 was born, the original LuaBridge is stagnating, too slow to move even the smallest steps, and i couldn't wait weeks before getting approvals or discussions to move forward.

[kunitoki]

@dmitry-t ping

[rpatters1]

I would love to see a LuaBridge organization! I am the developer of the Finale plugin RGP Lua, and while some of the code is proprietary, I have loaded as much of it as I am I legally allowed to into the Finale Lua organization, which also includes a large script repository. We created the organization to try to avoid what happened with the original Lua on Finale plugin, where the developer went offline and it froze.

All by way of saying, that with a LuaBridge org, there would be less ambiguity about which LuaBridge I should be using. I have been using v2, but I am very attracted to some of the features of v3 and will probably migrate in the near future.

[kunitoki]

I agree, but it seems like the original LuaBridge authors have just left the project and the current maintainer doesn't seem to be online much to take care of it.