Support exporting structs as a reference

[wfltaylor]

The current mechanism for exporting structs works great for simple structs, like @JS struct Point { let x: Double; let y: Double }. When passed out or into Swift, all the members of the struct are copied.

However, it is also common in Swift to have a less trivial struct, for example:

@JS struct Polygon {

    var vertices: [Point]

}

A complex polygon could have tens of thousands of vertices. This works fine in Swift, since the Array is COW. However, this is less than ideal when interoperating with JavaScript, where all the vertices would have to be copied every time the struct crosses the boundary.

Mutating functions currently don’t work on structs, but if they were working, this would also require copying the whole contents of the struct after each call. For example, a mutating addVertex function on Polygon would require copying every vertex across the boundary.

To workaround this issue, you could convert the struct into a class. This improves interoperability with JavaScript, however it can make Swift code less idiomatic.

Proposed Solution

A solution would be allowing structs to be exported using a heap allocated box, which could be expressed using @JS(boxed: true). A “boxed” struct would lead to very similar generated code to a class, where JavaScript just has a Swift-owned pointer.

[krodak]

Hey @wfltaylor, I understand below suggestion does not resolve the issue, but it might help until we have boxing mechanism in place.

If you switch both Polygon and Point to classes and enable identity mode, BridgeJS maintains a WeakRef-based cache keyed by the Swift heap pointer. The same Swift object always returns the same JS wrapper, so you avoid recreating wrapper objects on every boundary crossing. Point needs to be a class too, otherwise the [Point] array still copies every vertex as a value type when it crosses the boundary.

Per-class opt-in with the macro:

@JS(identityMode: true)
class Point {
    @JS var x: Double
    @JS var y: Double
    @JS init(x: Double, y: Double) { self.x = x; self.y = y }
}

@JS(identityMode: true)
class Polygon {
    @JS var vertices: [Point]
    // ...
}

There's also a project-wide option in bridge-js.config.json:

{ "identityMode": "pointer" }

This turns on identity caching for every class in the target. I'd go with the per-class macro though - it makes the intent explicit at the declaration site, and you avoid paying the cache overhead (Map, WeakRef, FinalizationRegistry) for simple types that don't need it. Per-class @JS(identityMode: true/false) overrides the config setting either way.

I developed identity mode because of similar issues - repeated crossings creating redundant wrappers was a real pain point. Combined with making these types classes, JS only holds a pointer to the Swift heap object, so vertices never cross the boundary unless you explicitly access them. Mutating methods just work since you're calling into the same heap-allocated instance.

The @JS(boxed: true) idea for structs would be better fit for more idiomatic approach, we've discussed it a while back and I think both @MaxDesiatov and @kateinoigakukun were in favor of it long term AFAIR