Paolo Bonzini <[email protected]> writes: > On 12/9/25 11:03, Markus Armbruster wrote: >> * Why is util::qobject::QObject needed? >> >> * NONE is an error value, not a valid QType. Having such error values >> in enums isn't unusual in C. What about idiomatic Rust? Even if it's >> unusual there, we may elect to do it anyway, just to keep generated >> Rust closer to C. But it should be a conscious decision, not a blind >> port from C to Rust. > > For QType we don't need to keep it closer, but actually ABI-compatible: > QType is defined by QAPI but is used (almost exclusively) by QObject. > We use the C version in the QObject bindings, for example: > > $($crate::bindings::QTYPE_QNULL => break $unit,)?
I see. Worth a comment. >> * "Default for QType" is NONE. In C, it's zero bytes, which boils down >> to QTYPE_NONE. >> >> * QTYPE__MAX is a bit of a headache in C. It's not a valid enum value. >> We make it one only because we need to know the largest valid enum >> value, e.g. to size arrays, and the easiest way to get that value is >> adding an invalid one to the enum. Same for all the other generated >> enums. Could we avoid it in Rust? > > Yes, I think so. > >> * C has a file comment of the form >> >> /* >> * One-line description of the file's purpose >> * >> * Copyright lines >> * >> * License blurb >> */ >> >> I think Rust could use such a comment, too. > > Ok. > >> * C has built-in types like QType in qapi-builtin-types.h, generated >> only with -b. This is a somewhat crude way to let code generated for >> multiple schemas coexist: pass -b for exactly one of them. If we >> generated code for built-in types unconditionally into qapi-types.h, >> the C compiler would choke on duplicate definitions. Why is this not >> a problem with Rust? > > Because there's better namespacing, so it's okay to define the builtin > types in more than one place. However, do we need at all the builtin > types in Rust? QType is only defined in QAPI to have the nice enum > lookup tables, and we can get it via FFI bindings. Lists, as you say > below, are not needed, and they are also a part of qapi-builtin-types.h. > > So I think Rust does not need built-in types at all, which I think > solves all your problems here (other than _MAX which can be removed). Let's try this. >> * The Rust version doesn't have deallocation boilerplate. Deallocation >> just works there, I guess. >> >> * The Rust version doesn't have the List type. Lists just work there, I >> guess. > > Yep. > >> * The Rust version doesn't have the implicit type q_obj_my_command_arg, >> which is the arguments of my-command as a struct type. C needs it for >> marshaling / unmarshaling with visitors. Rust doesn't, because we use >> serde. Correct? > > Commands are not supported at all yet. > > Paolo Thanks!
