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

Replacing "might" with "can" obscures the distinction of possiblity and risk #4389

Open
tkoeppe opened this issue Nov 24, 2020 · 0 comments
Open

Comments

@tkoeppe
Copy link
Contributor

tkoeppe commented Nov 24, 2020

This is a tracking issue for a discussion that arose from the "could"/"might" wording changes.

We initially proposed replacing "might" with "can" in several cases, but this has a different nuance that might not be desirable.

As @zygoloid puts it:

I prefer the nuance of "might" here, as we're talking about a thing that might unfortunately happen to an unsuspecting programmer, not something they can choose to do.

I wonder if that's a good barometer in general: using "can" to discuss risks seems like it has the wrong nuance.

We have multiple instances where "might" is used to call out a risk, not a possiblity.

Additional feedback on "might" => "can" changes:

This note to me sounds like it's directed at the programmer, not the implementation, and the change from "might" to "can" reverses that. So this is at least a change in nuance.

[Re "f might throw" vs "f can throw" or "it is possible for f to throw":] This is stating something as fact that is not known to be true -- we don't know whether it's possible for f to throw because we haven't seen its definition. (There's a surprisingly subtle difference between "X might Y" and "it is possible for X to Y" here.)

See the discussions in #4384 for context.

I expect that we will want to rephrase the offending phrases more widely than by just replacing one word with another.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant