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
This is essentially a union(enum(u32)) that you receive, it would be a neat QoL to just declare the extern interop type as such from the start rather than manually checking the type field and returning your custom Ziggified tagged union to wrap it.
But then that would have the problem of being able to mutate the type field separately from the data field, so not sure what the right solution would be here.
Another consideration is the use of anonymous unions, i.e. DUMMYUNIONNAME, which extracts their fields into the parent scope, e.g.
typedefstructtagSOMEDATA {
UINTcbSize;
DWORDdwType;
union {
variant0: SOMEVARIANT0;
variant1: SOMEVARIANT1;
variant2: SOMEVARIANT2;
} DUMMYUNIONNAME; // anonymous union
} SOMEDATA, *PSOMEDATASOMEDATAmydata= {
.cbSize=sizeof(SOMEDATA);
.dwType=0;
.variant1=myVariant1Details; // treated as if the union variant is in parent scope
}
The text was updated successfully, but these errors were encountered:
On Windows there are a lot of functions where you provide buffer and the system writes a struct to it that are essentially a tagged union:
This is essentially a
union(enum(u32))
that you receive, it would be a neat QoL to just declare the extern interop type as such from the start rather than manually checking the type field and returning your custom Ziggified tagged union to wrap it.Perhaps something like
But then that would have the problem of being able to mutate the type field separately from the data field, so not sure what the right solution would be here.
Another consideration is the use of anonymous unions, i.e.
DUMMYUNIONNAME
, which extracts their fields into the parent scope, e.g.The text was updated successfully, but these errors were encountered: