From 1b51c917d0c83a4270ed9acfdc793a8a01591201 Mon Sep 17 00:00:00 2001
From: Anthony Williams <anthony@justsoftwaresolutions.co.uk>
Date: Tue, 4 Oct 2016 16:51:44 +0100
Subject: [PATCH] Expanded CP.50 to reference synchronized_value<T>

---
 CppCoreGuidelines.md | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md
index 5466995..fd69278 100644
--- a/CppCoreGuidelines.md
+++ b/CppCoreGuidelines.md
@@ -12712,11 +12712,13 @@ Flag all unnamed `lock_guard`s and `unique_lock`s.
 
 
 
-### <a name="Rconc-mutex"></a>P.50: Define a `mutex` together with the data it guards
+### <a name="Rconc-mutex"></a>P.50: Define a `mutex` together with the data it guards. Use `synchronized_value<T>` where possible
 
 ##### Reason
 
-It should be obvious to a reader that the data is to be guarded and how.
+It should be obvious to a reader that the data is to be guarded and how. This decreases the chance of the wrong mutex being locked, or the mutex not being locked. 
+
+Using a `synchronized_value<T>` (see the [WG21 proposal](http://wg21.link/p0290)) ensures that the data has a mutex, and the right mutex is locked when the data is accessed.
 
 ##### Example
 
@@ -12725,6 +12727,13 @@ It should be obvious to a reader that the data is to be guarded and how.
         // ...
     };
 
+    class MyClass {
+        struct DataRecord {
+           // ...
+        };
+        synchronized_value<DataRecord> data; // Protect the data with a mutex
+    };
+
 ##### Enforcement
 
 ??? Possible?