What version of Go are you using (go version)?

1.10.2

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Not relevant

What did you do?

When writing a code such as

x.RLock()
defer x.RUnlock()

it is tempting to write defer x.Unlock() instead of defer x.RUnlock(), which will cause an error if the mutex was not write-locked.

I suggest to not only be explicit when read-(un)locking but also when write-(un)locking by renaming Lock() to WLock() and Unlock() to WUnlock(). That way, it will be really easy to see if there is a potential bug because the code will look like:

x.RLock()
defer x.WUnlock()

which is way more explicit. If this code is involuntary, then ther'es a high chance the dev will spot the bug easily, and if it was meant to be like that (which I suppose is not common at all), then it's way better for it to be explicit (because not common)

I am writing this issue because I saw this bug happens 2 times in production over the course of the week and it feels like a really simple, common-sense fix to do.