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
{{ message }}
This repository was archived by the owner on Mar 25, 2026. It is now read-only.
dom_wasmjs_gopherjs.go: (go1.12 && wasm && js) || js which is a complex way of writing js.
dom_native.go: go1.12 && !wasm && !js
I am unsure about what exactly is intended here. From the comments in dom_native.go, it looks like the intent was for dom_wasmjs_gopherjs.go to apply to js/wasm builds and dom_native.go to apply otherwise. That would be:
dom_wasmjs_gopherjs.go: go1.12 && js && wasm
// +build go1.12,js,wasm
dom_native.go: !(go1.12 && js && wasm) which is !go1.12 || !js || !wasm
I've been analyzing
// +build usagein the Go ecosystem and turned up dom_wasmjs_gopherjs.go, which says:and dom_native.go which says:
These two conditions are:
dom_wasmjs_gopherjs.go:
(go1.12 && wasm && js) || jswhich is a complex way of writingjs.dom_native.go:
go1.12 && !wasm && !jsI am unsure about what exactly is intended here. From the comments in dom_native.go, it looks like the intent was for dom_wasmjs_gopherjs.go to apply to js/wasm builds and dom_native.go to apply otherwise. That would be:
dom_wasmjs_gopherjs.go:
go1.12 && js && wasmdom_native.go:
!(go1.12 && js && wasm)which is!go1.12 || !js || !wasmBest,
Russ