CC @golang/js

Thanks for your proposal. Could you elaborate a little on what you have to do today? I'm just trying to understand exactly what the benefit is here. Do you have a practical example which would be greatly simplified with this change? Thanks!

yes, so basically, I'm making go channel iterable in js.
When I doing something will use lots time, it's better to return a channel than an array, because I can render the data already processed before all stuffs are done.

Example is at https://github.com/kmcsr/mcla/blob/main/cmds/mcla_wasm/utils.go#L67

Without symbols when I want to iter it, I have to call

let value;
while(!({value} = await iter.next()).done){
  /* do something with value */
}

if with iterator symbol, I can use for ... of, it's much simple than while next

for await (let value of iter){
  /* do something with value */
}

As you can see, the first example while next is I already compressed, if it should be step by step, then it will be:

while(true){
  let res = await iter.next()
  if(res.done){
    break
  }
  let value = res.value
  /* do something with value */
}

@johanbrandhorst Any progress?

No one is working on this as far as I know. If you want to work on this, feel free to experiment with it.

Change https://go.dev/cl/555417 mentions this issue: syscall/js: add methods GetSymbol, SetSymbol, and DeleteSymbol

Thanks for opening a CL, I think this has to go through the proposal review process before we can merge it, but it's a great start! I think this sounds like a reasonable addition to the syscall/js package and you make a compelling case that this provides a significant boost to developer ergonomics without adding much maintenance burden. Could the proposal review committee add this to the next review?

Further proposal: Is it necessary to wrap an async channel in std? so other people do not need to write same logic again and again

I'm not sure what you mean - in any case, please write a separate issue for this proposal.