code.h uses MS-only C++ extensions

[zooba]

Issue #100222 added a struct to Include/cpython/code.h (which is included by default by Python.h) that is not compliant C++:

typedef union {
    uint16_t cache;
    struct {
        uint8_t opcode;
        uint8_t oparg;
    };
} _Py_CODEUNIT;

The struct member requires a name, as only anonymous structs are currently permitted in standard C++.

(And since the original issue invokes PEP 7, I'll do the same and point out that "The public C API should be compatible with C++". The intention of this clause is that standard C++ can #include <Python.h>, which is currently broken.)

Linked PRs

• gh-101907: Removes use of non-standard C++ extension from Include/cpython/code.h #101909
• gh-101907: Stop using _Py_OPCODE and _Py_OPARG macros #101912

[markshannon]

Rather than replace all the .opcode and .oparg with SHOUTY MACROS, how about:

typedef union {
    uint16_t cache;
    struct {
        uint8_t code;
        uint8_t arg;
    } op;
} _Py_CODEUNIT;

Then i.oparg becomes i.op.arg which is still readable.

[zooba]

Do we want that to be the API then? And so we should remove the macros entirely?

If we're going to have macros, I'd rather they be the only place we have to make a change like this.

[markshannon]

Personally, I'd say get rid of the macros.

At least the uses of them. We should probably keep the declarations in case any third-party code is using them.