refactor: "expression templates" renamed to "symbolic expressions"

docs/appendix/glossary.md

@@ -270,7 +270,7 @@
 [`derived dimension`](#derived-dimension){ #derived-dimension }
 
 :   - A [dimension](#dimension) of a [derived quantity](#derived-quantity).
-    - Implemented as an expression template being the result of the
+    - Implemented as an symbolic expression being the result of the
       [dimension equation](#dimension-equation) on [base dimensions](#base-dimension).
 
 [`dimension equation`](#dimension-equation){ #dimension-equation }

docs/getting_started/faq.md

@@ -159,7 +159,7 @@ The above prints:
 
 Some users could expect to see `42 kWh` or `42 kW h` in the output. It is not the case and for
 a very good reason. As stated in
-[Simplifying the resulting expression templates](../users_guide/framework_basics/interface_introduction.md#simplifying-the-resulting-expression-templates),
+[Simplifying the resulting symbolic expressions](../users_guide/framework_basics/interface_introduction.md#simplifying-the-resulting-symbolic-expressions),
 to be able to reason about and simplify units, the library needs to order them in an appropriate
 order.
 

docs/getting_started/introduction.md

@@ -35,7 +35,7 @@ To achieve this goal, several techniques are applied:
   compile-times and the readability of error messages when compared to the traditional template
   metaprogramming with [SFINAE](https://en.cppreference.com/w/cpp/language/sfinae),
 - [usage of strong types for framework entities](../users_guide/framework_basics/interface_introduction.md#strong-types-instead-of-aliases) (instead of type aliases),
-- [usage of expression templates](../users_guide/framework_basics/interface_introduction.md#expression-templates) to improve the readability of generated types,
+- [usage of symbolic expressions](../users_guide/framework_basics/interface_introduction.md#symbolic-expressions) to improve the readability of generated types,
 - limiting the number of template arguments to the bare minimum.
 
 !!! important "Important: It is all about errors"

docs/users_guide/framework_basics/dimensionless_quantities.md

@@ -141,7 +141,7 @@ ratio of `1` and does not output any textual symbol.
 !!! important "Important: `one` is an identity"
 
     A unit `one` is special in the entire type system of units as it is considered to be
-    [an identity operand in the unit expression templates](interface_introduction.md#identities).
+    [an identity operand in the unit symbolic expressions](interface_introduction.md#identities).
     This means that, for example:
 
     ```cpp

docs/users_guide/framework_basics/interface_introduction.md

@@ -24,7 +24,7 @@ behind this is that:
 
     Also, to prevent possible issues in compile-time logic, all of the library's entities must be
     marked `final`. This prevents the users to derive own strong types from them, which would
-    prevent expression template simplification of equivalent entities.
+    prevent symbolic expressions simplification of equivalent entities.
 
 ## Strong types instead of aliases
 
@@ -103,14 +103,14 @@ inline constexpr struct joule  final : named_unit<"J", newton * metre> {} joule;
 ```
 
 
-## Expression templates
+## Symbolic expressions
 
 The previous chapter provided a rationale for not having predefined types for derived entities.
 In many libraries, such an approach results in long and unreadable compilation errors, as
 framework-generated types are typically far from being easy to read and understand.
 
 The **mp-units** library greatly improves the user experience by extensively using
-expression templates. Such expressions are used consistently throughout the entire library
+symbolic expressions. Such expressions are used consistently throughout the entire library
 to describe the results of:
 
 - [dimension equation](../../appendix/glossary.md#dimension-equation) - the result is put into
@@ -169,7 +169,7 @@ constexpr auto my_unit = one / second;
     constexpr auto my_unit = inverse(second);
     ```
 
-    Both cases will result in the same expression template being generated and put into the wrapper
+    Both cases will result in the same symbolic expression being generated and put into the wrapper
     class template.
 
 
@@ -195,10 +195,10 @@ its unique representation in the library:
 | `sqrt({identity})` or `pow<1, 2>({identity})` |              `{identity}`               |
 
 
-### Simplifying the resulting expression templates
+### Simplifying the resulting symbolic expressions
 
 To limit the length and improve the readability of generated types, there are many rules to simplify
-the resulting expression template.
+the resulting symbolic expression.
 
 1. **Ordering**
 
@@ -246,7 +246,7 @@ the resulting expression template.
 
     Also, to prevent possible issues in compile-time logic, all of the library's entities must be
     marked `final`. This prevents the users to derive own strong types from them, which would
-    prevent expression template simplification of equivalent entities.
+    prevent symbolic expression simplification of equivalent entities.
 
 4. **Repacking**
 

docs/users_guide/framework_basics/systems_of_units.md

@@ -96,7 +96,7 @@ All of the above quantities are equivalent and mean exactly the same.
 
     The above code example may give the impression that the order of components in a derived
     unit is determined by the multiplication order. This is not the case. As stated in
-    [Simplifying the resulting expression templates](interface_introduction.md#simplifying-the-resulting-expression-templates),
+    [Simplifying the resulting symbolic expressions](interface_introduction.md#simplifying-the-resulting-symbolic-expressions),
     to be able to reason about and simplify units, the library needs to order them in an
     appropriate order. This will affect the order of components in a resulting type and
     text output.