Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tour: #42 (Mutating Maps) redundant explanation #7500

Closed
gopherbot opened this issue Mar 9, 2014 · 5 comments
Closed

x/tour: #42 (Mutating Maps) redundant explanation #7500

gopherbot opened this issue Mar 9, 2014 · 5 comments

Comments

@gopherbot
Copy link

by oneorjuan:

Check the last 2 paragraphs of the "Mutating Maps" chapter:
http://tour.golang.org/#42

"If key is in m, ok is true. If not, ok is false and elem is the zero value for the
map's element type.

Similarly, when reading from a map if the key is not present the result is the zero
value for the map's element type."

They say the same thing with very similar words, making one to think that maybe the
second paragraph is actually an errata and it was supposed to explain something else.
@robpike
Copy link
Contributor

robpike commented Mar 26, 2014

Comment 1:

Labels changed: added repo-tour.

Owner changed to @adg.

Status changed to Accepted.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@rsc rsc removed accepted labels Apr 14, 2015
@rsc rsc changed the title http://tour.golang.org/#42 (Mutating Maps) redundant explanation x/tour: #42 (Mutating Maps) redundant explanation Apr 14, 2015
@rsc rsc modified the milestones: Unreleased, Unplanned Apr 14, 2015
@rsc rsc removed the repo-tour label Apr 14, 2015
@kytrinyx
Copy link
Contributor

kytrinyx commented Oct 8, 2015

These are not exactly equivalent, as the first sentence refers to the two-value assignment, and the second refers to a read (m[key]).

Perhaps something like this would feel less echo-y:

If `key` is in `m`, `ok` is `true`. If not, `ok` is `false`.

If `key` is not in the map, then `elem` is the zero value for the map's
element type, both when reading from `m` and when using the two-value
assignment.

@adg
Copy link
Contributor

adg commented Oct 8, 2015

How about just this:

If key is in m, ok is true. If not, ok is false.

If key is not in the map, then elem is the zero value for the map's element type.

@kytrinyx
Copy link
Contributor

kytrinyx commented Oct 8, 2015

Yeah, on re-reading it, I think that would work. At first glance it seems like it might only refer to the example immediately above, but it's pretty safe to assume that people will infer that the behavior is the same for the read as for the two-value assignment.

I'll make the change.

@adg
Copy link
Contributor

adg commented Oct 8, 2015

Thanks!

On 8 October 2015 at 16:59, Katrina Owen notifications@github.com wrote:

Yeah, on re-reading it, I think that would work. At first glance it seems
like it might only refer to the example immediately above, but it's pretty
safe to assume that people will infer that the behavior is the same for the
read as for the two-value assignment.

I'll make the change.


Reply to this email directly or view it on GitHub
#7500 (comment).

@golang golang locked and limited conversation to collaborators Oct 9, 2016
gopherbot pushed a commit to golang/website that referenced this issue May 26, 2021
The duplication is not exact. The first reference is to the
two-value assignment, and the second sentence refers to reads.

However, it is fairly safe to assume that readers will infer that
the explanation is valid for both contexts.

Fixes golang/go#7500

Change-Id: I93903c0be27099ced34a6808cdb4f0a65dc5f2e6
Reviewed-on: https://go-review.googlesource.com/15602
Reviewed-by: Andrew Gerrand <adg@golang.org>
X-Tour-Commit: 258270064d09854eec74df7efae0fa1e2e24607b
@rsc rsc unassigned adg Jun 23, 2022
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
The duplication is not exact. The first reference is to the
two-value assignment, and the second sentence refers to reads.

However, it is fairly safe to assume that readers will infer that
the explanation is valid for both contexts.

Fixes golang/go#7500

Change-Id: I93903c0be27099ced34a6808cdb4f0a65dc5f2e6
Reviewed-on: https://go-review.googlesource.com/15602
Reviewed-by: Andrew Gerrand <adg@golang.org>
X-Tour-Commit: 258270064d09854eec74df7efae0fa1e2e24607b
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants