Yes, It's a type error.

What about:

export let a = 1;

Since the value will be copied it won't be mutable, I hope that it won't create confusion for users.

@xtuc Yes, I can see how some people may expect a live binding rather than a snapshot. That's sort of a different, cross-cutting issue, though: functions are also proposed to have their semantics based on a snapshot, rather than a live binding. Also, if you replace one WebAssembly.Global object with another in your export, it's proposed that importing modules will still point to the original one. Overall, supporting live bindings by default would lead to significant additional complexity for WebAssembly semantics (what would it mean for Tables and Memory?!).

The thing is that user won't keep a handle on a bare number export, as opposed to WebAssembly.{Table,Memory,Global}.

If i'm not mistaken,

export let a = 1;
a = 2;

will snapshot a constant 2, but they won't be able to mutate it after.

export let a = 1;
export function t() {
  a = 2;
}

This has no precedence in JS (that i'm aware of at least) and I think that it will confuse some users.

Also the change will only be visible in JS.

Live bindings "by default" could be archived using functions, which would return the up-to-date number. This has a noticable perf impact.

Bindings are not live in these semantics for functions either. Do you think that will be confusing?