docs: "i.e." replaced with "e.g." everywhere in the project

CONTRIBUTING.md

@@ -6,7 +6,7 @@
 
 The easiest way to start coding is to jump straight into [Gitpod](https://www.gitpod.io). You can either click the button
 below or prefix any `mp-units` URL (main branch, other branches, issues, PRs, ...) in your web browser with `gitpod.io/#`
-(i.e. <https://gitpod.io/#https://github.com/mpusz/units>).
+(e.g. <https://gitpod.io/#https://github.com/mpusz/units>).
 
 [![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/mpusz/units)
 

docs/appendix/glossary.md

@@ -71,7 +71,7 @@
 :   - Expression of the dependence of a [quantity](#quantity) on the [base quantities](#base-quantity)
       of a [system of quantities](#system-of-quantities) as a product of powers of factors corresponding
       to the [base quantities](#base-quantity), omitting any numerical factor.
-        - i.e. in the [ISQ](#isq), the quantity dimension of force is denoted by $\textsf{dim }F = \mathsf{LMT}^{–2}$.
+        - e.g. in the [ISQ](#isq), the quantity dimension of force is denoted by $\textsf{dim }F = \mathsf{LMT}^{–2}$.
     - A power of a factor is the factor raised to an exponent. Each factor is the dimension
       of a [base quantity](#base-quantity).
     - In deriving the dimension of a quantity, no account is taken of its scalar, vector, or
@@ -130,7 +130,7 @@
           ($\mathsf{1/s}$) is called hertz ($\mathsf{Hz}$) when used for frequencies and
           becquerel ($\mathsf{Bq}$) when used for activities of radionuclides. As another example,
           the joule ($\mathsf{J}$) is used as a unit of energy, but never as a unit of moment of
-          force, i.e. the newton metre ($\mathsf{N·m}$).
+          force, e.g. the newton metre ($\mathsf{N·m}$).
     - Measurement units of [quantities of dimension one](#dimensionless-quantity) are
       numbers. In some cases, these measurement units are given special names, e.g. radian,
       steradian, and decibel, or are expressed by quotients such as millimole per mole equal
@@ -141,7 +141,7 @@
 :   - [Measurement unit](#unit) that is adopted by convention for a [base quantity](#base-quantity).
     - In each [coherent system of units](#coherent-system-of-units), there is only one base unit
       for each [base quantity](#base-quantity).
-        - i.e. in the [SI](#si), the metre is the base unit of length. In the CGS systems,
+        - e.g. in the [SI](#si), the metre is the base unit of length. In the CGS systems,
           the centimetre is the base unit of length.
     - A base unit may also serve for a [derived quantity](#derived-quantity) of the same
       [quantity dimension](#dimension).
@@ -280,9 +280,9 @@
 [`quantity kind hierarchy, quantity hierarchy`](#quantity-hierarchy){ #quantity-hierarchy }
 
 :   - [Quantities of the same kind](#kind) form a hierarchy that determines their:
-        - convertibility (i.e. every width is a length, but width should not be
+        - convertibility (e.g. every width is a length, but width should not be
           convertible to height)
-        - common quantity type (i.e. width + height -> length)
+        - common quantity type (e.g. width + height -> length)
 
 [`quantity character, character of a quantity, character`](#character){ #character }
 
@@ -316,7 +316,7 @@
         - [dimension of a quantity](#dimension)
         - [quantity kind](#kind)
         - [quantity character](#character)
-        - additional constraints (i.e. non-negative)
+        - additional constraints (e.g. non-negative)
     - [Dimension of a quantity](#dimension) is not enough to specify all the properties of
       a [quantity](#quantity).
 

docs/getting_started/faq.md

@@ -28,7 +28,7 @@ Many reasons make UDLs a poor choice for a physical units library:
    `K` (kelvin), `d` (day), `l` or `L` (litre), `erg`, `ergps`. For a while for those we used `_` prefix
    to make the library work at all, but at some point, we had to unify the naming, and we came up with `_q_`
    prefix, which resulted in creating a quantity of a provided unit. So in case the library is
-   standardized, all quantities would be created with UDLs having `q_` prefix (i.e. `42q_s`)
+   standardized, all quantities would be created with UDLs having `q_` prefix (e.g. `42q_s`)
    which is not that nice anymore.
 
 4. UDLs with the same identifiers defined in different namespace can't be disambiguated in the C++
@@ -154,7 +154,7 @@ code.
 Both C++ and [ISO 80000](../appendix/references.md#ISO80000) are standardized by the ISO.
 [ISO 80000](../appendix/references.md#ISO80000) and the [SI](../appendix/references.md#SIBrochure)
 standards specify Unicode symbols as the official unit names for some quantities
-(i.e. `Ω` symbol for the resistance quantity).
+(e.g. `Ω` symbol for the resistance quantity).
 As **mp-units** library will be proposed for standardization as a part of the C++ Standard Library
 we have to obey the rules and be consistent with ISO specifications.
 

docs/getting_started/installation_and_usage.md

@@ -137,7 +137,7 @@ tools.cmake.cmaketoolchain:generator="Ninja Multi-Config"
 
     In such a case, you will need to use a configuration-specific preset name in the Conan instructions
     provided below rather then just `conan-default` and `conan-release`
-    (i.e. `conan-gcc-11` and `conan-gcc-11-release`)
+    (e.g. `conan-gcc-11` and `conan-gcc-11-release`)
 
 
 ## Build Options

docs/users_guide/framework_basics/basic_concepts.md

@@ -344,7 +344,7 @@ satisfied by all types being or deriving from and instantiation of a `quantity`
     All of `42 * m`, `42 * si::metre`, `42 * isq::height[m]`, and `isq::height(42 * m)` create a quantity
     and thus satisfy a `Quantity` concept.
 
-    A quantity type can also be specified explicitly (i.e. `quantity<si::metre, int>`,
+    A quantity type can also be specified explicitly (e.g. `quantity<si::metre, int>`,
     `quantity<isq::height[m]>`).
 
 ### `QuantityOf<T, V>` { #QuantityOf }

docs/users_guide/framework_basics/generic_interfaces.md

@@ -72,7 +72,7 @@ some issues start to be clearly visible:
     quantity<isq::speed[m / s]> s3 = avg_speed((20 * m).force_in(km), (2 * s).force_in(h));
     ```
 
-    but the above will obviously provide an incorrect behavior (i.e. division by `0` in the evaluation
+    but the above will obviously provide an incorrect behavior (e.g. division by `0` in the evaluation
     of `s3`).
 
 

docs/users_guide/framework_basics/interface_introduction.md

@@ -40,7 +40,7 @@ to improve the user experience while debugging the program or analyzing the comp
 ## Entities composability
 
 Many physical units libraries (in C++ or any other programming language) assign strong types
-to library entities (i.e. derived units). While `metre_per_second` as a type may not look too
+to library entities (e.g. derived units). While `metre_per_second` as a type may not look too
 scary, consider, for example, units of angular momentum. If we followed this path, its
 [coherent unit](../../appendix/glossary.md#coherent-derived-unit) would look like
 `kilogram_metre_sq_per_second`. Now, consider how many scaled versions of this unit would you
@@ -74,7 +74,7 @@ auto q = la_vector{1, 2, 3} * isq::angular_momentum[kg * m2 / s];
 ```
 
 It is a much better solution. It is terse and easy to understand. Please also notice how
-easy it is to obtain any scaled version of such a unit (i.e. `mg * square(mm) / min`)
+easy it is to obtain any scaled version of such a unit (e.g. `mg * square(mm) / min`)
 without having to introduce hundreds of types to predefine them.
 
 
@@ -207,8 +207,8 @@ the resulting expression template.
     static_assert(std::is_same_v<decltype(A * B), decltype(B * A)>);
     ```
 
-    This is probably the most important of all steps, as it allows comparing types and enables the rest of
-    simplification rules.
+    This is probably the most important of all the steps, as it allows comparing types and enables
+    the rest of simplification rules.
 
 2. **Aggregation**
 

docs/users_guide/framework_basics/quantity_arithmetics.md

@@ -9,7 +9,7 @@ properly constrained set of arithmetic operations on one or two operands.
 
     Every single arithmetic operator is exposed by the `quantity` class template only if
     the underlying representation type provides it as well and its implementation has proper
-    semantics (i.e. returns a reasonable type).
+    semantics (e.g. returns a reasonable type).
 
 For example, in the following code, `-a` will compile only if `MyInt` exposes such an operation
 as well:

docs/users_guide/framework_basics/simple_and_typed_quantities.md

@@ -24,7 +24,7 @@ class quantity;
 
 The concept `Reference` is satisfied by either:
 
-- a unit with an associated quantity type (i.e. `si::metre`)
+- a unit with an associated quantity type (e.g. `si::metre`)
 - a reference type explicitly specifying the quantity type and its unit.
 
 !!! important
@@ -397,7 +397,7 @@ related to quantities, this should be the first function to look for.
 
 In case you wonder which mode you should choose for your project, we have good news for you.
 Simple and typed quantity modes can be freely mixed with each other. When you use different
-quantities of the same kind (i.e. radius, wavelength, altitude, ...), you should probably
+quantities of the same kind (e.g. radius, wavelength, altitude, ...), you should probably
 reach for typed quantities to bring additional safety for those cases. Otherwise, just use
 simple mode for the remaining quantities. The **mp-units** library will do its best to protect
 your project based on the information provided.

docs/users_guide/framework_basics/systems_of_quantities.md

@@ -56,8 +56,8 @@ physical properties.
 
     More than one quantity may be defined for the same dimension:
 
-    - quantities of _different kinds_ (i.e. frequency, modulation rate, activity, ...)
-    - quantities of _the same kind_ (i.e. length, width, altitude, distance, radius, wavelength, position vector, ...)
+    - quantities of _different kinds_ (e.g. frequency, modulation rate, activity, ...)
+    - quantities of _the same kind_ (e.g. length, width, altitude, distance, radius, wavelength, position vector, ...)
 
 It turns out that the above issues can't be solved correctly without proper modeling of
 a [system of quantities](../../appendix/glossary.md#system-of-quantities).

docs/users_guide/framework_basics/systems_of_units.md

@@ -7,7 +7,7 @@ quantities and provide automated conversion factors between various compatible u
 
 Probably all the libraries in the wild model the [SI](../../appendix/glossary.md#si)
 and many of them provide support for additional units belonging to various other systems
-(i.e. imperial).
+(e.g. imperial).
 
 
 ## Systems of Units are based on Systems of Quantities

docs/users_guide/framework_basics/text_output.md

@@ -36,7 +36,7 @@ inline constexpr bool space_before_unit_symbol<non_si::degree> = false;
 !!! note
 
     The above works only for [the default formatting](#default-formatting). In case we provide our own
-    format specification (i.e. `std::format("{:%Q %q}", q)`), the library will always obey this
+    format specification (e.g. `std::format("{:%Q %q}", q)`), the library will always obey this
     specification for all the units (no matter of what is the actual value of the
     `space_before_unit_symbol` customization point) and the separating space will always be present
     in this case.
@@ -130,17 +130,17 @@ In the above grammar:
   chapter of the C++ standard specification,
 - `units-text-encoding` tokens specify the unit text encoding:
     - `U` (default) uses the **Unicode** symbols defined by the [SI](../../appendix/glossary.md#si)
-      specification (i.e. `m³`, `µs`)
-    - `A` token forces non-standard **ASCII**-only output (i.e. `m^3`, `us`)
+      specification (e.g. `m³`, `µs`)
+    - `A` token forces non-standard **ASCII**-only output (e.g. `m^3`, `us`)
 - `units-unit-symbol-solidus` tokens specify how the division of units should look like:
     - `o` (default) outputs `/` only when there is only **one** unit in the denominator, otherwise negative
-      exponents are printed (i.e. `m/s`, `kg m⁻¹ s⁻¹`)
-    - `a` **always** uses solidus (i.e. `m/s`, `kg/(m s)`)
-    - `n` **never** prints solidus, which means that negative exponents are always used (i.e. `m s⁻¹`,
+      exponents are printed (e.g. `m/s`, `kg m⁻¹ s⁻¹`)
+    - `a` **always** uses solidus (e.g. `m/s`, `kg/(m s)`)
+    - `n` **never** prints solidus, which means that negative exponents are always used (e.g. `m s⁻¹`,
       `kg m⁻¹ s⁻¹`)
 - `units-unit-symbol-separator` tokens specify how multiplied unit symbols should be separated:
-    - `s` (default) uses **space** as a separator (i.e. `kg m²/s²`)
-    - `d` uses half-high **dot** (`⋅`) as a separator (i.e. `kg⋅m²/s²`)
+    - `s` (default) uses **space** as a separator (e.g. `kg m²/s²`)
+    - `d` uses half-high **dot** (`⋅`) as a separator (e.g. `kg⋅m²/s²`)
 
 
 ### Default formatting
@@ -266,7 +266,7 @@ std::println("{:%.3GQ %q}", 1.2345678e8 * m);    // 1.23E+08 m
 ### Unit symbol formatting
 
 Unit symbols of some quantities are specified to use Unicode signs by the
-[SI](../../appendix/glossary.md#si) (i.e. `Ω` symbol for the resistance quantity). The **mp-units**
+[SI](../../appendix/glossary.md#si) (e.g. `Ω` symbol for the resistance quantity). The **mp-units**
 library follows this by default. From the engineering point of view, sometimes Unicode text might
 not be the best solution as terminals of many (especially embedded) devices are ASCII-only.
 In such a case, the unit symbol can be forced to be printed using ASCII-only characters thanks to

docs/users_guide/framework_basics/the_affine_space.md

@@ -2,8 +2,8 @@
 
 The affine space has two types of entities:
 
-- **_point_** - a position specified with coordinate values (i.e. location, address, etc.)
-- **_vector_** - the difference between two points (i.e. shift, offset, displacement, duration, etc.)
+- **_point_** - a position specified with coordinate values (e.g. location, address, etc.)
+- **_vector_** - the difference between two points (e.g. shift, offset, displacement, duration, etc.)
 
 
 !!! note
@@ -236,7 +236,7 @@ Taxi distance:   31.2544 km
 !!! note
 
     It is not allowed to subtract two point origins defined in terms of `absolute_point_origin`
-    (i.e. `mean_sea_level - mean_sea_level`) as those do not contain information about the unit
+    (e.g. `mean_sea_level - mean_sea_level`) as those do not contain information about the unit
     so we are not able to determine a resulting `quantity` type.
 
 

example/glide_computer_lib/include/glide_computer_lib.h

@@ -47,7 +47,7 @@
 // - thermals exactly where and when we need them ;-)
 // - no airspaces
 // - ground level changes linearly between waypoints
-// - no ground obstacles (i.e. mountains) to pass
+// - no ground obstacles (e.g. mountains) to pass
 // - flight path exactly on a shortest possible line to destination
 
 namespace glide_computer {

src/core/include/mp-units/bits/sudo_cast.h

@@ -36,7 +36,7 @@ template<Quantity From, Quantity To>
 {
   if constexpr (requires { typename std::common_type_t<typename From::rep, typename To::rep>; })
     // returns a common type of two representation types if available
-    // i.e. `double` and `int` will end up with `double` precision
+    // e.g. `double` and `int` will end up with `double` precision
     return std::common_type_t<typename From::rep, typename To::rep>{};
   else
     return typename From::rep{};

src/core/include/mp-units/bits/value_cast.h

@@ -34,7 +34,7 @@ namespace mp_units {
  * @brief Explicit cast of a quantity's unit
  *
  * Implicit conversions between quantities of different types are allowed only for "safe"
- * (i.e. non-truncating) conversion. In truncating cases an explicit cast have to be used.
+ * (e.g. non-truncating) conversion. In truncating cases an explicit cast have to be used.
  *
  * auto d = value_cast<si::second>(1234 * ms);
  *
@@ -59,7 +59,7 @@ template<Unit auto ToU, typename Q>
  * @brief Explicit cast of a quantity's representation type
  *
  * Implicit conversions between quantities of different types are allowed only for "safe"
- * (i.e. non-truncating) conversion. In truncating cases an explicit cast have to be used.
+ * (e.g. non-truncating) conversion. In truncating cases an explicit cast have to be used.
  *
  * auto q = value_cast<int>(1.23 * ms);
  *

src/core/include/mp-units/unit.h

@@ -68,8 +68,8 @@ inline constexpr bool is_specialization_of_scaled_unit<scaled_unit<M, U>> = true
  * @brief A named unit
  *
  * Defines a unit with a special name. It may be used to provide a base unit in the system
- * of units (i.e. `metre`) or a name assigned to another scaled or derived unit
- * (i.e. `hour`, `joule`).
+ * of units (e.g. `metre`) or a name assigned to another scaled or derived unit
+ * (e.g. `hour`, `joule`).
  * Most of the named units may be composed with a prefix to create a `prefixed_unit`.
  *
  * For example:
@@ -135,7 +135,7 @@ struct named_unit<Symbol> {
 /**
  * @brief Specialization for a unit with special name
  *
- * Allows assigning a special name to another scaled or derived unit (i.e. `hour`, `joule`).
+ * Allows assigning a special name to another scaled or derived unit (e.g. `hour`, `joule`).
  *
  * @tparam Symbol a short text representation of the unit
  * @tparam Unit a unit for which we provide a special name