Rationale

Rationale

1. Why to implement composer for policy in place of using variadic templates.

1.	Why to implement composer for policy in place of using variadic templates.
	Policies can be complex and reusable. We want to allow users to define them using the using keyword for that purpose. Composer allows easily to do that.

1.1. Why not all policies derive from same class?

1.1. Why not all policies derive from same class?
1.1.	Why not all policies derive from same class?
	That generate problems with inheritance rules at the composer level making some methods be reported by compiler as hidden.

1.1. What is the difference between safefloat and what I can get from e.g. the Intel compiler by enabling FPEs?

1.1. What is the difference between safefloat and what I can get from e.g. the Intel compiler by enabling FPEs?
1.1.	What is the difference between safefloat and what I can get from e.g. the Intel compiler by enabling FPEs?
	In general, the main differences are Flexibility, customization of reporting, and multiplatform/compiler. Flexibility: Safefloat adds more granular control than FPE. FPE affects every variable in the system the same, while safefloat can be used to enforce some checks for a subgroup of all the floating point variables in the program or library, and even set different checks for different variables. Customization of reporting: Safefloat provides more options on how to react to failure. FPE will abort, while safefloat library provides different strategies to act when a check fails, it may be the case that you can expect a check to fail under certain conditions (exceptional behavior). An alternative would be to manually check flags after each operation, in place of doing that, safe float could throw an exception that can be handled properly. Multiplatform/compiler: Safefloat is C++17 standard compliand and it should work in any compiler implementing that standard.