Peter Xu <[email protected]> writes: > On Fri, Sep 04, 2026 at 10:41:21AM -0300, Fabiano Rosas wrote: >> >> + case QTYPE_QBOOL: { >> >> + QBool *b = qobject_to(QBool, obj); >> >> + if (b) { >> > >> > Similarly, I'd drop "if" if it will always happen, making qbool_get_bool() >> > assert itself by deref. >> > >> >> I'd rather not have such asserts in user-facing code. Even with testing, >> it's hard to ensure this 'obj' will reach here in integrity. > > Not a big deal here, but just for sake of pure discussion.. > > IMHO it's not the "user triggerable path" that we are avoiding assert()s, > but user input that may affect the result of the assert(). >
In this case, there should be none, agreed. > Here if we just checked obj type is QTYPE_QBOOL, I can't see anything that > can make this if not true. > Thanks for saying it explicitly, I wasn't seeing the obvious redundancy there. You're right, I'll remove the checks. > I still think assert() good guarding programming errors. Say, if something > we wanted to print here but skipped, I want it to crash hard, rather than > silently ignored.
