I think we may have to hold off on that one until generics are no longer guarded by the GOPHERJS_EXPERIMENT flag. Otherwise the standard library would no longer build for those who don't have the experiment enabled.

@nevkontakte In the go1.20 branch, the standard libraries don't built without the experiment flag as is. I have a bunch of overrides for a generic-less go1.20 in my WIP for g1.20. If you want to, I could pull those out and get them a PR for the go1.20 branch. I was getting close to a generic-less go1.20 (with the exception of that var _ = &Pointer[int]{} from go1.20.14/src/sync/atomic/type.go:40 that has to be manually removed right now). I wasn't PR'ing them since it felt like we were close enough to target a generic capable go1.20.

So, would you like me to cut some PR's for an almost generic-less go1.20, I could do that? Or I could just hold off on removing these for now but also not add more generic-less overrides, whatever helps the most.

We'll hold off on these changes until generics and go1.20 is further along.

The rule of thumb is that master branch must be usable by the general population at all times, even between releases. As such, we have two options:

• Implement a generic-less 1.20, which can be merged into master and released as another beta.
• Assume that we are okay holding off on 1.20 until generics are done. Then we can go all-in on using generics as much as we can in the 1.20 branch, but won't be able to merge it into master as soon.

I don't think I have a strong preference one way or another. It really depends on how deeply embedded generics are in the 1.20 version, and you probably have a better grasp on this than me :)

I was thinking we'd hold off on 1.20 until generics are done.

The big thing is the var _ = &Pointer[int]{} from go1.20.14/src/sync/atomic/type.go:40 that has to be manually removed right now. If we were going to target a generic-less 1.20, we'd have to figure out a way to delete that line from the natives. Since that line doesn't have a unique id for the augmenter to match, we'd either:

• match it by line number (which is not future resilient)
• find it by comparing specifications (which seems like it'd be slow)
• have something that looks for _ on lhs and checks that the rhs has no function body or anything which can have a side effect, e.g. var _ = func() int { /* do thing that has side effects */ }()
• make a PR into go's repo to remove that check

I'm not fond of any of those, so we'll just have to hold off on 1.20 until generics are done and make go1.20 branch a "needs generics enabled" branch until then.

I was thinking we'd hold off on 1.20 until generics are done.

Alright, I have no objections in this case. I'll take another look at this PR when I have a bit more time, and see if we can merge it.

We'll try to remove the overrides later in smaller chunks once the generics are further along.

go1.20 branch will still need GOPHERJS_EXPERIMENT="generics" since the go1.20.14 repo has stuff in it which won't compile without it and we can't (without a lot of effort) override that stuff.