Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

i signed it!

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

This PR (HEAD: 57a206b) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/187577 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

Message from Gobot Gobot:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
Within the next week or so, a maintainer will review your change and provide
feedback. See https://golang.org/doc/contribute.html#review for more info and
tips to get your patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11, it means that this CL will be reviewed as part of the next development
cycle. See https://golang.org/s/release for more details.

Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!

Message from Martin Möhrmann:

Patch Set 2: Code-Review-1

Thanks but please discuss this on the issue tracker first. This wont fix the inherent problem of a race when concurrently writing to the map while iterating over it. And if there are races of unsynchronised reading and writing then fmtsort does not need to protect against them as other hazards can still appear until there is proper synchronisation.

Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!

Message from Keith Randall:

Patch Set 2: Code-Review+1

I'm fine with this CL. It can only be triggered by a data race, but if there's something simple we can do to make the error better, we should.
We do something very similar in reflect.MapKeys:

The other options would be to:

1. panic with a better message if a concurrent write is detected
2. add a message about the concurrent write to the printed map
   Both would be better than the status quo.

Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!

Message from Martin Möhrmann:

Patch Set 2:

Patch Set 2: Code-Review+1

I'm fine with this CL. It can only be triggered by a data race, but if there's something simple we can do to make the error better, we should.
We do something very similar in reflect.MapKeys:

The other options would be to:

1. panic with a better message if a concurrent write is detected
2. add a message about the concurrent write to the printed map
   Both would be better than the status quo.

I would argue the better improvement here (if the panic should be avoided) would be to use append to add items to the slice as this will both handle more and less items than expected.

We probably should add a comment why this is programmed defensively so it is not optimised away by someone else later.

But I would rather as suggested add some marker/panic here that a race is observed than just avoiding the index panic.

Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!

Message from Brad Fitzpatrick:

Patch Set 2:

Patch Set 2:

Patch Set 2: Code-Review+1

I'm fine with this CL. It can only be triggered by a data race, but if there's something simple we can do to make the error better, we should.
We do something very similar in reflect.MapKeys:

The other options would be to:

1. panic with a better message if a concurrent write is detected
2. add a message about the concurrent write to the printed map
   Both would be better than the status quo.

I would argue the better improvement here (if the panic should be avoided) would be to use append to add items to the slice as this will both handle more and less items than expected.

We probably should add a comment why this is programmed defensively so it is not optimised away by someone else later.

But I would rather as suggested add some marker/panic here that a race is observed than just avoiding the index panic.

And I'd like to see a test. Is there a valid way that this change can matter that's not a data race? Do we not detect data races when reflect is used?

Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!

Message from 填佳 姚:

Patch Set 2:

Patch Set 2:

Patch Set 2:

Patch Set 2: Code-Review+1

I'm fine with this CL. It can only be triggered by a data race, but if there's something simple we can do to make the error better, we should.
We do something very similar in reflect.MapKeys:

The other options would be to:

1. panic with a better message if a concurrent write is detected
2. add a message about the concurrent write to the printed map
   Both would be better than the status quo.

I would argue the better improvement here (if the panic should be avoided) would be to use append to add items to the slice as this will both handle more and less items than expected.

We probably should add a comment why this is programmed defensively so it is not optimised away by someone else later.

But I would rather as suggested add some marker/panic here that a race is observed than just avoiding the index panic.

And I'd like to see a test. Is there a valid way that this change can matter that's not a data race? Do we not detect data races when reflect is used?

I'm sorry that i forgot to close this change. This issue #33275 has been solved in https://go-review.googlesource.com/c/go/+/191197

Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!