You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The main problem here, is that numbers are implicitly converted to strings, which has to actually replace the value on the Lua stack in-place, which can lead to all kinds of trouble. It also prevents their respective wrapper functions from being marked as const, even though only this single conversion actually has this problem.
Plan A would be to add new functions checkExact and atExact/toExact, that only work for exact types. The state and index wrapper functions can be marked as const.
The only real difference would be, that it prevents these implicit conversions:
number <-> string
any -> boolean
of which only number to string is actually posing problems.
Additionally, maybe something like this could make sense:
... but I'm not a 100% sure yet if that would be a great idea.
Plan B would be to ALWAYS use these exact conversions, since implicit conversions are rarely used like this anyways.
This also raises the question, if only the problematic number to string conversion should be disabled, or also string to number, which does not pose a problem. At the very least, any to boolean conversion should probably stay.
The text was updated successfully, but these errors were encountered:
The main problem here, is that numbers are implicitly converted to strings, which has to actually replace the value on the Lua stack in-place, which can lead to all kinds of trouble. It also prevents their respective wrapper functions from being marked as
const
, even though only this single conversion actually has this problem.Plan A would be to add new functions
checkExact
andatExact
/toExact
, that only work for exact types. The state and index wrapper functions can be marked asconst
.The only real difference would be, that it prevents these implicit conversions:
of which only number to string is actually posing problems.
Additionally, maybe something like this could make sense:
... but I'm not a 100% sure yet if that would be a great idea.
Plan B would be to ALWAYS use these exact conversions, since implicit conversions are rarely used like this anyways.
This also raises the question, if only the problematic number to string conversion should be disabled, or also string to number, which does not pose a problem. At the very least, any to boolean conversion should probably stay.
The text was updated successfully, but these errors were encountered: