Closes #1392

CppCoreGuidelines.md

@@ -12657,7 +12657,7 @@ If you really need to break out a loop, a `break` is typically better than alter
 ##### Reason
 
 Accidentally leaving out a `break` is a fairly common bug.
- A deliberate fallthrough is a maintenance hazard.
+A deliberate fallthrough can be a maintenance hazard and should be rare and explicit.
 
 ##### Example
 
@@ -12673,21 +12673,19 @@ If you really need to break out a loop, a `break` is typically better than alter
         break;
     }
 
-It is easy to overlook the fallthrough. Be explicit:
+Multiple case labels of a single statement is OK:
 
-    switch (eventType) {
-    case Information:
-        update_status_bar();
-        break;
-    case Warning:
-        write_event_log();
-        // fallthrough
-    case Error:
-        display_error_window();
+    switch (x) {
+    case 'a':
+    case 'b':
+    case 'f':
+        do_something(x);
         break;
     }
 
-In C++17, use a `[[fallthrough]]` annotation:
+##### Exceptions
+
+In rare cases if fallthrough is deemed appropriate, be explicit and use the `[[fallthrough]]` annotation:
 
     switch (eventType) {
     case Information:
@@ -12695,7 +12693,7 @@ In C++17, use a `[[fallthrough]]` annotation:
         break;
     case Warning:
         write_event_log();
-        [[fallthrough]];        // C++17
+        [[fallthrough]];        // C++17 (and legal but ignored since C++11)
     case Error:
         display_error_window();
         break;
@@ -12703,19 +12701,10 @@ In C++17, use a `[[fallthrough]]` annotation:
 
 ##### Note
 
-Multiple case labels of a single statement is OK:
-
-    switch (x) {
-    case 'a':
-    case 'b':
-    case 'f':
-        do_something(x);
-        break;
-    }
-
 ##### Enforcement
 
-Flag all fallthroughs from non-empty `case`s.
+Flag all implicit fallthroughs from non-empty `case`s.
+
 
 ### <a name="Res-default"></a>ES.79: Use `default` to handle common cases (only)