cc @golang/tools-team

Hashrefs in urls are not visible for servers. So the solution should be to add both IDs (doc-links and doclinks) for the target.

@dolmen Can you help us find where doc-links hashref is used?

I have used the hash ref in GitHub issues, PRs, Slack to tell people about godoc links.

@dolmen I fully understand how frustrating it is when old links no longer work. But I want to understand is what prevents from starting to use the new #doclinks. Is it to make the historical comments in old github issues, prs, and slack conversation valid?

The source of this link is in https://github.com/golang/website/blob/5c08bf3ee65177ad7160bd55d4a04bc613d6af9b/_content/doc/comment.md?plain=1#L610

As shown, this is a simplified markdown file, which the server processes and renders to a html file. We cannot remove doclinks which will break other users. I am not sure what to associate the extra hashref with.

If #doclinks is guaranteed to be stable from now, that's enough for my future use cases.

As the anchor seems to be defined in the document (and not by an algorithm) I expect that future breaking changes will be caught by code review. However a regression test on HTML anchors would be useful. Maybe this already somewhat exists if a test checks that links in the whole Go documentation are correctly resolved down to hashrefs.