move fail

src/SUMMARY.md

@@ -6,4 +6,3 @@
 - [Implementation]()
 - [Usage]()
 - [Current Implementation Concerns](./ch04/s00-concerns.md)
-  - [Fail Semantics](./ch04/s01-fail.md)

src/ch04/s00-concerns.md

@@ -9,6 +9,3 @@
 * Prevents using varied hash sizes.
   * Prevents using dynamic hash sizes.
 * Not a context-specific constant because associated `const`s in `const` context are unstable.
-
-## `Fail`/`FailMonad`/etc. have unclear semantics
-See the [relevant subchapter](./s01-fail.md)

src/ch04/s01-fail.md

@@ -1,16 +0,0 @@
-# Fail Semantics
-
-## Lack of proper support for injecting errors into classes that are already `Fail`
-* Classes have only one implementation of `Fail` per error type.
-* Proposed solutions:
-  * Have `Fail` as a separate trait with the error and the class as associated types.
-  * `OverloadClass` to mix-in additional `Fail`.
-
-## Lack of support for strict ordering of errors
-* Current (possible) implementations of having one error or another either allow short-circuiting
-on only one of them, or give them both the same priority.
-**Right now this model is considered the main one**,
-i.e. this restriction may get stabilised and standardised at some point.
-* More complex behaviours are expected to require a more complex execution model, with states
-taking messages from other states and optionally dropping their own execution, if their
-result\['s error\] is guaranteed to be "less sever" than the error it receives.