In Section 22.1, GPUDeviceLostInfo.reason is specified as:

readonly attribute (GPUDeviceLostReason or undefined) reason;

However the pattern, (T or undefined) is not consistent with other IDL files. There are very few uses like that as pointed out in #2784 (comment).

Furthermore, checking if something is undefined is often used to determine if a certain feature is implemented or not. In the case of GPUDeviceLostInfo, .reason is checked for equality with undefined in the device lost case to ensure the feature is implemented: https://github.com/gpuweb/cts/blob/main/src/webgpu/api/operation/adapter/requestDevice.spec.ts#L78. This is the opposite of what one may expect, specifically undefined meaning the feature, e.g., GPUDeviceLostInfo.reason, is not implemented.

In https://github.com/gpuweb/gpuweb/pull/2784/files, GPUObjectBase.label was changed from attribute (USVString or undefined) label; to attribute USVString label; with the comment that empty string was replacing the undefined state.

Similarly we could add a value to GPUDeviceLostInfo to signify this empty state. E.g.,

enum GPUDeviceLostReason {
    "",
    "destroyed",
};

or perhaps:

enum GPUDeviceLostReason {
    "unknown",
    "destroyed",
};

which is more consistent with other IDL files and avoids the use of checking with equality of undefined in a non-failure path as noted in the above test.

Can we consider either of these two alternatives in the specification instead of having a conforming implementation return undefined in a non-failure path?