I'm raising this proposal to have the discussion once. There are alternatives that exist today, but I figure this may be worth considering. I could not find a similar proposal in the backlog of open nor closed issues (no results for scoped mutex, nor sync locked).

I propose to add sync.Mutex.Locked(func()):

func (m *Mutex) Locked(fn func()) {
        m.Lock()
        defer m.Unlock()
        fn()
}

Benefits

• This can help eliminate a common problem of locking + deferring in loops.
• This can guard against recovered panics leaving the mutex in a locked state if the user is not using defer to unlock.
• Users are more incentivized to write functions without locks and rely on Locked to handle their synchronization, rather than embedding Lock / defer Unlock into the top of many functions.
• It looks visually cleaner than the inline anonymous function with defers (deemed BenchmarkUgly in the play link below).
• Users that have multiple unlock paths can be more incentivized to return from Locked and handle the result outside the lock/unlock paths.

Downsides

• This adds one function as overhead on sync.Mutex, whereas the current implementation is a strictly to the point mutex.
• Defer cannot be inlined at the moment (see cmd/compile: allow inlining of open-coded defer calls #38471), meaning the Locked function cannot be inlined, and neither can the function passed to it. Theoretically this slowness can be eliminated.
• The alternatives that exist today are fine and have existed since Go 1.0.

Code example / benchmarks

https://play.golang.org/p/Tll9rFTuPUM

goos: linux
goarch: amd64
pkg: j
cpu: Intel(R) Core(TM) i7-10710U CPU @ 1.10GHz
BenchmarkNative-12    	95955990	        10.82 ns/op
BenchmarkLocked-12    	72775494	        14.65 ns/op
BenchmarkUgly-12      	86551378	        13.73 ns/op