@nevkontakte TBH we probably don't need to have //gopherjs:override-signature forever. After go1.19 it could probably be removed since it was for a specific reason. There are also probably other simple ways to deal with this problem that I haven't thought of yet.

The main reason I added it was for some methods in crypto that have type parameters (e.g. func (curve *nistCurve[Point]) pointFromAffine(x, y *big.Int) (p Point, err error)). I did not want to copy/paste and maybe accidentally mess up cryptology for GopherJS. Since it dealt with generics //gopherjs:keep-original would not work for what we needed. So I felt it was better to just override the signature as a way to remove the type parameters and replace the type parameter usage in the arguments with a wrapper object that implements the methods called inside of that function. It wouldn't have worked if the type parameter was for a specific type constraint (e.g. func Sort[S ~[]E, E cmp.Ordered](x S)) instead of an interface constraint. Here is how I used that in the native override files.

@nevkontakte I also added to doc/pragma.md. I'm very dyslexic and make grammar/spelling mistakes all the time so if you find anything I need to correct please let me know. I try really hard to triple check anything I write (sadly English is my only language, if you don't count science 😄. I joke a lot about dreaming in math but not in English).

Thanks for the explanation! I was not opposed to addition of the directive per se, but I wanted to make sure I fully understand the logic behind it instead of making my own assumptions :)

I did not want to copy/paste and maybe accidentally mess up cryptology for GopherJS.

That's actually a strong argument. Messing with cryptography makes bad things happen 🙃

I'm very dyslexic and make grammar/spelling mistakes all the time so if you find anything I need to correct please let me know.

That makes the two of us, as you may have notices from typos in comments 😄 No worries! If I spot anything, I'll let you know.