Comments (18)
Why not post it in #82? One could argue that if you don't need to pass anything as parameter then it should be wrapped with std::optional
. But I understand backward compatibility. It's up to kunitoki how he wants to handle it.
from luabridge3.
I mainly posted a new issue because it is to report the bug that omitting lua boolean parameters causes true
to be sent to C++. That's a flat-out bug.
It also appears that at least Stack::get will get a boolean value as true if it is anything other than nil or nothing or false.
from luabridge3.
Concerning breaking changes, to me this situation appears similar to what happened with the introduction of integer types in Lua 5.3. By default, Lua 5.3 would emit a runtime error when you assigned a non-integer floating point value to an integer property. (At least, to an integer property created by LuaBridge on a C++ class.)
This was a massive breaking change and a huge barrier to adoption. It is the reason that my project never progressed past 5.2 for 6 years. I recently decided to investigate the issue further and discovered that Lua offers a compile-time macro to truncate floats into integers instead of issuing runtime errors. I am advocating something similar with LuaBridge 3 and omitted booleans, because unless this issue is addressed I can't use LB3. And I really do want to use it.
from luabridge3.
If you declare the method with bool, but call it without parameters, that should raise a lua error. We should gradually move to use optional for optional parameters.
from luabridge3.
If you declare the method with bool, but call it without parameters, that should raise a lua error.
I don't disagree, but it is a breaking change. I think it is important not to let the perfect be the enemy of the good.
from luabridge3.
The reason i took over luabridge3 was to make things consistent and more aligned with how modern C++ works as well, regardless of breaking changes. This code is more than 10 years old, and what was good 10 years ago, might not be so good nowadays.
from luabridge3.
regardless of breaking changes.
Breaking changes are a big deal. In putting all this work into LB3, surely you would prefer to see wider rather than narrow adoption. Breaking changes are a major impediment to adoption. Your statement is pretty much the definition of making the perfect be the enemy of the good: almost never a good choice.
And consider that the older = value
will always be the easier choice for optional parameters. The vast, vast majority of C++ functions use them over std::optional
and will for the foreseeable future. By sticking to your policy, you are telling users of LB3 they either have to modify 3rd party libraries to use std::optional
instead, or they have to laboriously comb through their code and replace the registrations of such functions with proxy functions. There has to be an easier way. Neither of the others is going to happen.
All that said, I think we can agree that the current behavior of sending true
to C++ constructors when a boolean parameter is omitted is clearly and obviously the wrong choice. That's the main fix I need at the moment. I'll take either runtime error or false
.
I may be prepared to eat the breaking change for omitted boolean params. Indeed, you will find that I complained about this from the opposite side in the LB2 repo, but since no fix would ever be forthcoming, I embraced the behavior. Now I'll have to de-embrace it and go find and fix any documentation I wrote that allowed it.
from luabridge3.
Here's a test case:
class foo
{
bool val_;
public:
foo(bool param) : val_(param) {}
bool val() const { return val_; }
};
luabridge::getGlobalNamespace(L)
.beginNamespace("foobar")
.beginClass<foo>("foo")
.addConstructor<void(*)(bool)>()
.addFunction("val", &foo::val)
.endClass()
.endNamespace();
local foo = foobar.foo()
print (foo:val()) -- > prints "true"
In this case foo:val()
should either print "false", or foobar.foo()
should throw a runtime error. On LB2 it is the former behavior. (foo:val()
returns false
.)
from luabridge3.
Some design decisions in LB2 are also questionable. Breaking changes are surely annoying, but all changes come at a cost, if not, this would be LB 2.0.1 not 3.0.0.
Btw, thanks for the repro case.
from luabridge3.
If only there were a way to treat an old-style optional parameter as std::optional
in LB3. It's cumbersome to have to write proxies for them. I wonder if it would be possible to flag them when they are registered.
from luabridge3.
The idiomatic way to pass optionals in C++ is std::optional nowadays.
from luabridge3.
Here's a test case:
Pushed a fix to master
from luabridge3.
The idiomatic way to pass optionals in C++ is std::optional nowadays.
So say many C++ purists, but it will never be true. = value
optionals are part of the language, and they will never go away. There are 40 years of legacy C++ code written with = value
and more being added every day. I would bet there is more added every day now in 2023 than there is std::optional
being written.
The syntax of = value
is much less cumbersome and easier to read, and all but the most dedicated c++ purists will continue to use it.
from luabridge3.
they serve different purposes.
from luabridge3.
I agree. They serve different purposes C++. The issue is, how to port a function with default arguments into Lua with LB3. What I wish for is a way we could mark the default arguments to be treated as std::optional inside LB. This would allow Lua programs to call the same way C++ functions do.
I realize it can be done with proxy functions. I spent a couple of hours this morning trying to write a generic proxy function to let default arguments be optional in Lua, but even with ChatGPT helping I couldn't get it to work. I've discovered that when I ask ChatGPT to do something that isn't really possible I get wrong code from it. 🤣
from luabridge3.
My code is working now, so I will close this issue. We still have #82 to track the larger question.
from luabridge3.
I usually wrap the methods i can't change with lambdas.
from luabridge3.
Yes, what I was thinking about was whether is a way to make that wrapping process less cumbersome. So far I haven't com up with one.
from luabridge3.
Related Issues (20)
- Compiler error use of deleted function luabridge::TypeResult<T>::TypeResult(...) HOT 6
- Enhancement Request: Custom error function for `lua_pcall`. HOT 11
- Error C3861 (using with Luau) HOT 3
- Can I cast types inside Lua? HOT 4
- Duplicate symbols on Win32 with default __stdcall HOT 9
- Debug names of C functions for Luau HOT 8
- Extensible class bug with inheritance
- Add support for addStaticIndexMetamethod and addStaticNewIndexMetamethod
- Using LuaBridge3 in a precompiled header on MSVC leads to an internal compiler error HOT 2
- Use of std::shared_ptr on classes without `std::enable_shared_from_this` HOT 1
- Stateful lambdas registered as functions loose state HOT 2
- Compile error with Cfunc property getter/setter HOT 2
- std::vector to 0-based Lua table HOT 5
- MSC Warning C4146 HOT 2
- How to expose C++ data (a vector, in this case) to Lua without making a copy? HOT 2
- Does LuaBridge3 Support Android for SDL2-based Games? HOT 2
- Passing a Lua Table (LuaRef) as an argument to C++ function HOT 1
- How to get the name of a Lua variable? HOT 2
- Comparison Issue Between `uint64_t` in C++ and Numeric Constant in Lua HOT 8
- NAI run lua code in string from cpp
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from luabridge3.