welder 0.1.0
Bindings for annotated C++ types, from C++26 reflection
Loading...
Searching...
No Matches
metamethods.hpp File Reference

The C++-operator → Lua metamethod name map, shared by both Lua runtime rods (sol2 and LuaBridge3). More...

#include <meta>
#include <welder/bind_traits.hpp>
Include dependency graph for metamethods.hpp:
This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Namespaces

namespace  welder
namespace  welder::rods
namespace  welder::rods::lua

Functions

consteval const char * welder::rods::lua::lua_metamethod_name (std::meta::info f)
 Map a member operator to its Lua metamethod __name, or nullptr if welder does not expose it (which also gates operator eligibility in the driver).

Detailed Description

The C++-operator → Lua metamethod name map, shared by both Lua runtime rods (sol2 and LuaBridge3).

Lua's metamethod model is one set of __name slots regardless of which C++ wrapper lays the bindings down, so the which operators are exposed and under what __name decision lives here, once, and each rod reuses it:

The map reflects Lua's metamethod model, which differs from Python's dunders in three ways:

  • No __ne/__gt/__ge. Lua synthesizes ~=, > and >= from __eq, __lt and __le (operands swapped), so operator!=, operator> and operator>= map to nothing — they already work in Lua once ==/</<= are bound.
  • ^ is XOR, not power. C++ operator^ maps to Lua's bitwise-xor metamethod __bxor, not __pow (which is Lua's ^).
  • Bitwise metamethods are Lua ≥ 5.3 only (__band, __bor, __bxor, __bnot, __shl, __shr) — absent on Lua 5.1 / LuaJIT — so they are #if-gated on LUA_VERSION_NUM.

Requires the welder vocabulary first (#include <welder/vocabulary.hpp>) and the Lua headers (<lua.h>, pulled in by <sol/sol.hpp> / <LuaBridge/LuaBridge.h>) so LUA_VERSION_NUM is visible.

Definition in file metamethods.hpp.