This seems like a worthwhile improvement. Count me as a +1
I have a question:
What do you anticipate _sl_reserved being used for, or is it really just padding?
If you do anticipate a use, could we give it a name that might make that usage easier in future?
And a comment:
The struct
typedef struct PySlot {
uint16_t sl_id;
uint16_t sl_flags;
union {
uint32_t _sl_reserved; // must be 0
};
union {
void *sl_ptr;
void (*sl_func)(void);
Py_ssize_t sl_size;
int64_t sl_int64;
uint64_t sl_uint64;
};
} PySlot;
contains anonymous unions.
I thought we generally avoided anonymous unions in the API, as C++ doesn’t support them.
How about:
union _Py_slot_value {
void *ptr;
void (*func)(void);
Py_ssize_t size;
int64_t int64;
uint64_t uint64;
};
typedef struct PySlot {
uint16_t sl_id;
uint16_t sl_flags;
uint32_t _sl_reserved; // must be 0
union _Py_slot_value sl_val;
} PySlot;
So, instead of:
{
.sl_id=Py_tp_getattro,
.sl_flags=PySlot_HAS_FALLBACK,
.sl_func=myClass_getattro,
},
you’d have
{
.sl_id=Py_tp_getattro,
.sl_flags=PySlot_HAS_FALLBACK,
.sl_val.func=myClass_getattro,
},