Gracefully handle unavailable JSBridgedClass

[MaxDesiatov]

Force unwrapping in class var constructor may crash for classes that are unavailable in the current environment. For example, after swiftwasm/WebAPIKit#38 was merged, it led to crashes in getCanvas calls due to these optional casts relying on class var constructor always succeeding:

    public static func construct(from value: JSValue) -> Self? {
        if let canvasRenderingContext2D: CanvasRenderingContext2D = value.fromJSValue() {
            return .canvasRenderingContext2D(canvasRenderingContext2D)
        }
        if let gpuCanvasContext: GPUCanvasContext = value.fromJSValue() {
            return .gpuCanvasContext(gpuCanvasContext)
        }
        if let imageBitmapRenderingContext: ImageBitmapRenderingContext = value.fromJSValue() {
            return .imageBitmapRenderingContext(imageBitmapRenderingContext)
        }
        if let webGL2RenderingContext: WebGL2RenderingContext = value.fromJSValue() {
            return .webGL2RenderingContext(webGL2RenderingContext)
        }
        if let webGLRenderingContext: WebGLRenderingContext = value.fromJSValue() {
            return .webGLRenderingContext(webGLRenderingContext)
        }
        return nil
    }

if let gpuCanvasContext: GPUCanvasContext = value.fromJSValue() branch crashes on browsers that don't have GPUCanvasContext enabled.

As we currently don't have a better way to handle unavailable features, I propose making the result type of static var constructor requirement optional. This means you can still declare classes that are unavailable in the host JS environment. Conditional type casts are also available as they were, they will just always return nil, and initializers for these classes will return nil as well.

[MaxDesiatov]

Fix applied by the formatter.

[MaxDesiatov]

Fix applied by the formatter, as the rest of similar changes here.

[github-actions]

Time Change: +140ms (1%)

Total Time: 13,963ms

Test name	Duration	Change
Serialization/Write JavaScript string directly	352ms	+18ms (5%)	🔍

View Unchanged

Test name	Duration	Change
Serialization/Write JavaScript number directly	299ms	-9ms (3%)
Serialization/Swift Int to JavaScript	4,456ms	+23ms (0%)
Serialization/Swift String to JavaScript	4,540ms	+87ms (1%)
Object heap/Increment and decrement RC	4,317ms	+22ms (0%)

[MaxDesiatov]

Trying this in swiftwasm/WebAPIKit#41, looks like there's more work to do. Marking this PR as a draft, but I'm still looking forward to any feedback on this as a general approach.

[j-f1]

For types like these where the global must be available, how do you feel about declaring constructor as JSFunction!?

[MaxDesiatov]

I tried this, but then you have to add an explicit JSFunction? type signature on top, which means you still have to unwrap with ! or ? wherever this constructor is used. So after all, there's no benefit of unwrapping it and then wrapping back again into JSFunction? to satisfy the protocol requirement.

[j-f1]

Ah, I had remembered the Foo! and Foo? types being compatible with each other but it seems that isn’t the case (i.e. you can’t conform to a protocol with a Foo? requirement using a member of type Foo!). So this seems like the best approach. 👍

[j-f1]

Overall I like this! I had been contemplating adding a Boolean supported class var but this is a much better approach.

[MaxDesiatov]

I've verified that this fully works with WebAPIKit, ready for review.

[kateinoigakukun]

Ah, I missed this PR