
I've been having great fun in the Lean dependent type system, so it's high time I wrote about pattern matching!
# What is pattern matching?

Pattern matching is a mechanism for deconstructing data types by directly matching against their structure and binding components to variables. For production software, native pattern matching support in a language helps with type safety, reducing defensive checks and making illegal/not-well-defined states unreachable. For formal verification, this is how we prove propositions -- each case is a proof obligation.

By C++17 we'd gotten `std::variant`, `std::visit`, and structured bindings as an [approximation for a non-native way](https://bitbashing.io/std-visit.html#fn:2) to pattern match. 

```cpp
#include <variant>
#include <iostream>

struct Zero {};
struct Succ {
    int value;
};

using Nat = std::variant<Zero, Succ>;

template<class... Ts>
struct overloaded : Ts... {
    using Ts::operator()...;
};

template<class... Ts>
overloaded(Ts...) -> overloaded<Ts...>;

void printNat(const Nat& n) {
    std::visit(overloaded{
        [](const Zero&) {
            std::cout << "Zero\n";
        },
        [](const Succ& s) {
            std::cout << "Succ with value: " << s.value << "\n";
        }
    }, n);
}

int main() {
    Nat zero = Zero{};
    Nat succ = Succ{42};

    printNat(zero); // Output: Zero
    printNat(succ); // Output: Succ with value: 42
}
```

The `std::variant` is a discriminated union/sum type that allows runtime polymorphism without requiring inheritance or virtual functions. `std::visit` dispatches the right callable (lambda in this example) based on the active type in the `std::variant`. Since `std::visit` only takes a single callable object but we want to use different lambdas based on the different possible underlying types (`Zero`/`Succ`), we use the `overloaded` struct to combine multiple lambdas together into a single callable. This is cleverly achieved by inheriting from all the lambdas and using template parameter pack expansion `(Ts... )`, and then bringing all the `operator()` overloads together into the struct via `using Ts::operator()...;`. Then we use CTAD in `overloaded(Ts...) -> overloaded<Ts...>;` to let the compiler automatically deduce the types of the lambdas passed to `overloaded`. 

Since we wrote this without a generic fallback, exhaustiveness is enforced -- we get a (pretty gnarly) compilation error if we add in some other type to the variant without adding a corresponding case in the `std::visit`. We don't have exhaustiveness checking provided natively, and we also don't have matching on multiple fields or nested matching.

In Lean this is easier on the eyes:

``` lean
inductive Nat : Type where
  | zero : Nat
  | succ : Nat → Nat

def isZero (n : Nat) : Bool :=
  match n with
  | Nat.zero => true
  | Nat.succ _ => false
  
#eval isZero Nat.zero -- `true`
#eval isZero (Nat.succ Nat.zero) -- `false`
```

We inductively define a `Nat` type with a base case `Nat.zero` and an inductive successor case `Nat.succ`. Then `isZero` pattern matches on the structure of `Nat`. The native language support in Lean means handling of all possible cases is enforced, and values are automatically destructured and bound.

# Dependent type systems ...and match?

Actually, Lean takes it a step further by supporting full dependent types. A dependent type is a type that can depend on runtime values. 

``` lean
def BoolToType x :=
  match x with
  | true => Nat
  | false => String
  
axiom n : Nat

axiom x : BoolToType (n % 2 == 0)
```
* This convoy example is from stepchowfun's Lean tutorial series! See [Sources](#sources)

Here the type of `x` depends on whether the value of `n` is even or odd. And let's say we want to do different things with `x` depending on the different types it could be. You might try naively pattern matching:

``` lean
-- #check
--   match n % 2 == 0 with
--   | true => x + 1
--   | false => x.length
```

But this is an issue -- Lean can't infer the specific type of `x` based on what it knows about `n`. Naive pattern matching doesn't work because it doesn't do *type refinement* on the result for each case such that each branch only needs to consider the specific value corresponding to that case. You'll get compiler errors on both match cases above. Specifically, in both branches `x` still has type `BoolToType (n % 2 == 0)`, which is why we can't use it as `Nat` or `String`.

# The convoy pattern and dependent pattern matching

Instead, let's use dependent pattern matching and the convoy pattern to "lift" the runtime value into the compile time type system. We construct a function which accepts an arbitrary value of the dependent type. Then we immediately call that function on the value we have, `x`. Dependent pattern matching means when we match on a value, it causes types mentioning that value to get refined.

``` lean
#check
  (
    match n % 2 == 0 with
    | true => fun y => @id Nat y + 1
    | false => fun y => y.length
    : BoolToType (n % 2 == 0) → Nat
  ) x
```

The key here is Lean creates an equality proof in each branch. For the `true` case Lean knows `n % 2 == 0 = true`, so `BoolToType (n % 2 == 0)` reduces to `BoolToType true` . Then we can use `@id Nat` to force `y`'s `BoolToTrue` type to be reduced to `Nat` type, which is needed for *type class resolution* of which `+` operator to use (`@ id` means the identity function with implicit arguments disabled). In the `false` case, Lean knows `n % 2 == 0 = false`, and the `.length` method directly tells Lean `y` 's type should be reduced down to a `String` via *method resolution*. 

And using the equality proof to carry information learned about each case of `x` is quite neat! Indeed, that's the essence of the convoy pattern: that information is convoyed/escorted into each branch to be refined, which enables expressiveness while maintaining type safety. (To be clear, naive pattern matching does maintain type safety too, by being conservative and rejecting.)

# Why can't C++ do something like this?

Stepping back, the answer lies in the differences in how C++ and Lean are compiled, and what each language wants to achieve.

In general, C++ has a hard wall between compile and run time. Types are checked at compile time, and values are computed at runtime. Types have to be erased before runtime for performance. C++ guarantees zero-cost abstraction, which means no runtime overhead for type safety. But by definition, dependent types depend on runtime values. On the other hand, Lean doesn't mind adding compilation time -- as an interactive theorem prover, Lean wants that compile-time correctness.

# Sources

[https://lean-lang.org/theorem_proving_in_lean4/Dependent-Type-Theory/#dependent-type-theory](https://lean-lang.org/theorem_proving_in_lean4/Dependent-Type-Theory/#dependent-type-theory)

[https://lean-lang.org/functional_programming_in_lean/Programming-with-Dependent-Types/#Functional-Programming-in-Lean--Programming-with-Dependent-Types](https://lean-lang.org/functional_programming_in_lean/Programming-with-Dependent-Types/#Functional-Programming-in-Lean--Programming-with-Dependent-Types)

[https://github.com/stepchowfun/proofs/tree/main/proofs_lean/tutorial](https://github.com/stepchowfun/proofs/tree/main/proofs_lean/tutorial)



Pattern Matching


>These are my notes while going through the book [Design Patterns in Modern C++20: Reusable Approaches for Object-Oriented Software Design](https://www.oreilly.com/library/view/design-patterns-in/9781484272954/) by Dmitri Nesteruk. Since they're notes, I may have direct code examples or quotes, and may omit things that may be notable to you but aren't to me. I definitely encourage getting a copy of this book for full context!

# CRTP (Curiously Recurring Template Pattern)

Key idea: inheritor passes itself as a template argument to its base class. One reason to do this: access a typed `this` pointer in a base class implementation: Let's say every child class of `SomeBase` has a `begin()/end()` defined for iteration. Can you iterate the object in a member of `SomeBase` instead of in the child class? `SomeBase` doesn't itself provide a `begin()/end()`, so you may think no! but using CRTP, derived class can pass information about *itself* to the base class:
``` cpp
struct MyClass : SomeBase<MyClass>
{
  class iterator {
	// your iterator defined here
  }
  iterator begin() const { ... }
  iterator end() const { ... }
}
```
so inside the base class you can cast `this` to a derived class type:
``` cpp
template <typename Derived>
struct SomeBase
{
  void foo()
  {
	for (auto& item : *static_cast<Derived*>(this))
	{
	  ...
	}
  }
}
```
What happens here when calling `MyClass::foo()`: `this` pointer gets cast from `SomeBase*` to `MyClass*` , the pointer gets dereferenced and iterated on using that range-based `for` which calls the `MyClass::begin()/end()`.

# Mixin Inheritance

Key idea: a class can be defined to inherit from its own template argument, allowing hierarchical composition of types.

``` cpp
template <typename T> struct Mixin : T
{
  ...
}
```

You can make an instance of `Foo<Bar<Baz>> x;` that implements traits of all three classes without having to construct a whole new `FooBarBaz` type. This is really useful with Concepts! We can clearly and elegantly constrain the type our mixin inherits from to use base type features without having to look at compile-time errors.

# Static Polymorphism

## First, the old-fashioned way:

Ex: building an alert systems that notifies via different mediums: email, SMS, Telegram, etc. With CRTP you can implement a base `Notifier` :

``` cpp
template <typename TImpl>
class Notifier {
public:
  void AlertSMS(string_view msg)
  {
    impl().SendAlertSMS(msg);
  }
  void AlertEmail(string_view msg)
  {
    impl().SendAlertEmail(msg);
  }
private:
  TImpl& impl() { return static_cast<TImpl&>(*this); }
  friend TImpl;
};
```

`TImpl` is a template argument, so compiler will check that `AlertSMS()` and `AlertEmail()` actually exist on the object, even though we didn't tell it that `TImpl` must inherit from `Notifier`.  So we can define this:

``` cpp
template <typename TImpl>
void AlertAllChannels(Notifier<TImpl>& notifier, string_view msg)
{
  notifier.AlertEmail(msg);
  notifier.AlertSMS(msg);
}
```

And then we can make `Notifier` implementations, like a no-op for testing:

``` cpp
struct TestNotifier: public Notifier<TestNotifier>
{
  void SendAlertSMS(string_view msg){}
  void SendAlertEmail(string_view msg){}
};

TestNotifier tn;
AlertAllChannels(tn, "testing!"); // just testing!
```

But this can be annoying because
- you have to have two separate, parallel APIs e.g. `AlertSMS/SendAlertSMS`
- the impl thing feels clunky. You'd expect base alert methods to be virtual and then impl class to override.
- `Timpl`'s interface isn't explicitly enforced, we just try to call them to check at runtime and rely on compiler errors.

## Now, with Concepts:

we can alleviate those issues by introducing a concept that requires those member functions:

``` cpp
template <typename TImpl>
concept IsANotifier = requires(TImpl impl) {
  impl.AlertSMS(string_view{});
  impl.AlertEmail(string_view{});
};
```

So we don't need the base `Notifier`:

``` cpp
template <IsANotifier TImpl>
void AlertAllChannels(TImpl& impl, string_view msg)
{
  impl.AlertSMS(msg);
  impl.AlertEmail(msg);
}

struct TestNotifier
{
  void AlertSMS(string_view msg) {}
  void AlertEmail(string_view msg) {}
};
```

# Properties

A property is just a combination of a (usually private) field and a getter/setter. This isn't part of the C++ standard (and you could implement this without any special language support), but we should mention the declaration specifier `property` you can use in most compilers:

``` cpp
class Person
{
  int age_;
public:
  int get_age() const { return age_; }
  void set_age(int value) { age_ = value; }
  __declspec(property(get=get_age, put=set_age)) int age;
};
```

Here `__declspec(property())` turns the getters and setters into virtual fields, so the compiler replaces any attempts to read/write to this field.

``` cpp
Person p;
p.age = 20; // calls p.set_age(20)
```

# SOLID Design Principles

## Single Responsibility Principle (SRP)

"Each class should have only one responsibility and therefore one reason to change."

Ex: A Journal class shouldn't have to deal with persistence/file saving, it should only need to change if e.g. you need to change how journal entries are stored. (Any situation that leads us to having to do a lot of tiny changes in lots of classes is probably a code smell!)

An extreme example of an antipattern here is the God object -- a huge class that tries to handle as many concerns as possible -- terrible monolithic monstrosity!
## Open-Closed Principle (OCP)

"open for extension but closed for modification" -- You shouldn't need to go back to code you've written and tested to change it.

Ex: You have a bunch of products, and you want to be able to filter them in many ways: by color, by size, by color and size...

``` cpp
enum class Color { Red, Green, Blue };
enum class Size { Small, Medium, Large };
struct Product
{
  string name;
  Color color;
  Size size;
};
```

Let's first separate (SRP) the filter (process that takes all items and only returns some) and the specification (the predicate definition to apply to a data element).

``` cpp
template <typename T> struct Specification
{
  virtual bool is_satisfied(T* item) = 0;
};

template <typename T> struct Filter
{
  virtual vector<T*> filter(
    vector<T*> items,
    Specification<T>& spec) const = 0;
};
```

Then the filter implementation is way simpler:

``` cpp
struct BetterFilter : Filter<Product>
{
  vector<Product*> filter(
    vector<Product*> items,
    Specification<Product>& spec) override
  {
    vector<Product*> result;
    for (auto& p : items)
      if (spec.is_satisfied(p))
        result.push_back(p);
    return result;
  }
};
```

And for actual specialized filters:

``` cpp
struct ColorSpecification : Specification<Product>
{
  Color color;
  explicit ColorSpecification(const Color color) : color{color} {}
  bool is_satisfied(Product* item) override {
    return item->color == color;
  }
};

Product apple{ "Apple", Color::Green, Size::Small };
Product tree{ "Tree", Color::Green, Size::Large };
Product house{ "House", Color::Blue, Size::Large };
vector<Product*> all{ &apple, &tree, &house };
BetterFilter bf;
ColorSpecification green(Color::Green);
auto green_things = bf.filter(all, green);
for (auto& x : green_things)
  cout << x->name << " is green";
```

And for compositional conditions:

``` cpp
template <typename T> struct AndSpecification : Specification<T>
{
  Specification<T>& first;
  Specification<T>& second;
  AndSpecification(Specification<T>& first,
    Specification<T>& second)
    : first{first}, second{second} {}
  bool is_satisfied(T* item) override
  {
    return first.is_satisfied(item) && second.is_satisfied(item);
  }
};

SizeSpecification large(Size::Large);
ColorSpecification green(Color::Green);
AndSpecification<Product> green_and_large{ large, green };
auto big_green_things = bf.filter(all, green_and_big);
for (auto& x : big_green_things)
  cout << x->name << " is large and green";
// Tree is large and green
```

>Side note: C++26 reflection + concepts can further make this way less clunky!

You can also embellish:

``` cpp
template <typename T> AndSpecification<T> operator&&
  (const Specification<T>& first,
   const Specification<T>& second)
{
  return { first, second };
}

SizeSpecification large(Size::Large);
ColorSpecification green(Color::Green);
auto big_green_things = bf.filter(all, green && large);
for (auto& x : big_green_things)
  cout << x->name << " is large and green" << endl;
```
## Liskov Substitution Principle (LSP)

"If an interface takes an object of type `Parent`, it should equally take an object of type `Child` without anything breaking."

Bad example:

``` cpp
class Rectangle
{
protected:
  int width, height;
public:
  Rectangle(const int width, const int height)
    : width{width}, height{height} { }
  int get_width() const { return width; }
  virtual void set_width(const int width) { this->width = width; }
  int get_height() const { return height; }
  virtual void set_height(const int height) { this->height = height; }
  int area() const { return width * height; }
};

class Square : public Rectangle
{
public:
  Square(int size): Rectangle(size,size) {}
  void set_width(const int width) override {
    this->width = height = width;
  }
  void set_height(const int height) override {
    this->height = width = height;
  }
};
```

Seems innocent, but then this easily blows up:

``` cpp
void process(Rectangle& r)
{
  int w = r.get_width();
  r.set_height(10);
  cout << "expected area = " << (w * 10)
    << ", got " << r.area() << endl;
}

Square s{5};
process(s); // expected area = 50, got 25
```

Ahh!!! Many possible solutions: perhaps the type `Square` shouldn't even exist and we should maybe use Factories for both rectangles and squares. Or maybe detect that a `Rectangle` is in fact a `Square`. You could also throw an exception but this would violate the "principle of least surprise" -- you'd probably expect a call to `set_width` to actually do something?
## Interface Segregation Principle (ISP)

"Split up interfaces so that implementers can pick and choose depending on their needs."

Ex: instead of having an interface for your multifunction printer that prints, scans, and faxes, you should have 3 separate interfaces for each.
## Dependency Inversion Principle (DIP)

"Depending on interfaces or base classes is better than depending on concrete types."
"Abstractions should not depend on details. Details should depend on abstractions."

We can achieve this via dependency injection:

Ex. Car has an engine, but needs to write to a log.

``` cpp
struct Engine
{
  float volume = 5;
  int horse_power = 400;
  friend ostream& operator<< (ostream& os, const Engine& obj)
  {
    return os
      << "volume: " << obj.volume
      << " horse_power: " << obj.horse_power;
  } // thanks, ReSharper!
};

struct ILogger
{
  virtual ~ILogger() {}
  virtual void Log(const string& s) = 0;
};

struct ConsoleLogger : ILogger
{
  ConsoleLogger() {}
  void Log(const string& s) override
  {
    cout << "LOG: " << s.c_str() << endl;
  }
};
```

Car needs both the engine and logging component. Let's define both of the dependent components as constructor parameters:

``` cpp
struct Car
{
  unique_ptr<Engine> engine;
  shared_ptr<ILogger> logger;
  Car(unique_ptr<Engine> engine,
      const shared_ptr<ILogger>& logger)
    : engine{move(engine)},
      logger{logger}
  {
    logger->Log("making a car");
  }
  friend ostream& operator<<(ostream& os, const Car& obj)
  {
    return os << "car with engine: " << *obj.engine;
  }
};
```

Then we bind `ILogger` to `ConsoleLogger`: "any time someone asks for an `ILogger` give them a `ConsoleLogger`"

```cpp
auto injector = di::make_injector(
  di::bind<ILogger>().to<ConsoleLogger>()
);
```

And now we can create our car:

``` cpp
auto car = injector.create<shared_ptr<Car>>();
```

So we have a `shared_ptr<Car>` pointing to a fully initialized `Car`, and to change the type of logger we just have to change a single place (the `bind` call) and then everywhere there's an `ILogger` it can now be the new logger. Helps with unit testing and allows us to use stubs/noops instead of mocks!


Design Patterns in Modern C++20

CppOnline26 Quiz Hunt


# Deducing `this`

> Python fans will love this one!

C++23 introduces the **explicit object parameter**, which allows the implicit `this` pointer in member functions to be made explicit. This is colloquially known as "deducing `this`". 

## Background & Motivation

Since C++03, member functions can have cv-qualifiers (`const` or `volatile`). It's common to see overloading based on these qualifiers. And since C++11, we can overload based on reference qualifiers. But that's quite verbose and not elegant! We'd have to rewrite the same logic many times, or delegate all methods to a separate `static` helper. Oftentimes, the only difference is in the types being accessed and used -- the implementation remains the same.

Pre-C++23, to perfectly forward the object itself (e.g., in a generic accessor or wrapper function), you needed all four overloads:

``` cpp
struct MyClass {
    void foo() & { /* lvalue non-const implementation */ }
    void foo() const & { /* lvalue const implementation */ }
    void foo() && { /* rvalue non-const implementation */ }
    void foo() const && { /* rvalue const implementation */ }
};
```

We want to be able to write a single member function template that can handle all combinations of `const`, non-`const`, l-value, and r-value references for the object on which it is called. 

## Enter C++23 deducing `this`.

With C++23 `this` keyword, we can condense all the perfect forwarding overloads into one generic implementation:

``` cpp
#include <utility>

struct MyClass {
    template <typename Self>
    void foo(this Self&& self) {
        // Use std::forward to preserve the original value category and constness
        internal_implementation(std::forward<Self>(self));
    }
};
```

As another benefit, we also get a cleaner implementation of the Curiously Recurring Template Pattern (CRTP). In traditional CRTP, the base class has to "know" the derived type via a template parameter. To access derived data, we have to cast the `this` pointer, which can be confusing for complex inheritance hierarchies, or if you accidentally cast to the wrong type. 

``` cpp
template <typename Derived>
struct Base {
    void interface() {
        // Confusion: 'this' is Base*, not Derived*. 
        // You MUST cast it, or the compiler won't see Derived's methods.
        static_cast<Derived*>(this)->implementation();
    }
};

struct Derived : Base<Derived> {
    void implementation() { /* ... */ }
};
```
If you have `struct Wrong : Base<Derived>`, the `static_cast` in the base class will compile but cause undefined behavior at runtime because it casts `Base` to a sibling type instead of itself. Confusing and hard to debug!

With C++23's deduced `this`, we can shift the template from class to function level, take out the `static_cast`, and have better type safety! The compiler can deduce the exact type of the object the method was called on, ensuring `self` is always the correct type. 

```cpp
struct Base {
    template <typename Self>
    void interface(this Self&& self) {
        // No static_cast needed! 
        // 'self' is automatically deduced as the Derived type.
        self.implementation();
    }
};

struct Derived : Base {
    void implementation() { /* ... */ }
};
```

Thirdly, deducing `this` greatly simplifies recursive lambda syntax. Traditionally, a lambda's body couldn't refer to itself because the object wasn't fully defined until the expression was complete. Here were some awkward workarounds:

- using `std::function`:

    ``` cpp
    #include <functional>
    #include <iostream>

    int main() {
        // Declare the std::function object first
        std::function<int(int)> fib = [&](int n) -> int {
            if (n <= 1) {
                return n;
            }
            // 'fib' is in scope here because it was declared previously
            return fib(n - 1) + fib(n - 2);
        };

        std::cout << "Fib(10) = " << fib(10) << std::endl; // Output: 55
    }
    ```
- using a generic lambda (with `auto&&` or `const auto&` parameter) that accepts itself as an argument to its own call operator, avoiding the overhead of `std::function`.
    ``` cpp
    #include <iostream>

    int main() {
        // The outer lambda defines the interface for the caller
        auto factorial = [](int n) {
            // The inner, generic lambda performs the actual recursion
            auto fact_impl = [](int n_val, const auto& self) -> int {
                if (n_val <= 1) {
                    return 1;
                }
                // Pass 'self' explicitly in the recursive call
                return n_val * self(n_val - 1, self);
            };
            // Initial call passes the implementation to itself
            return fact_impl(n, fact_impl);
        };

        std::cout << "Factorial(5) = " << factorial(5) << std::endl; // Output: 120
    }
    ```

- or the competitive programming variant defining the self-passing behavior directly:
    ``` cpp
    #include <iostream>

    int main() {
        // A single generic lambda that takes itself as the first argument
        auto fact = [&](auto&& self, int x) -> int {
            return x <= 1 ? 1 : x * self(self, x - 1);
        };

        std::cout << "Factorial(5) = " << fact(fact, 5) << std::endl; // Output: 120
    }
    ```
- in a functional manner, a generic Y-combinator (no, not the startup incubator, though that is what YC is named after) higher-order function can be defined. The Y-combinator takes a function that accepts "itself" as its first argument and handles the recursive binding automatically. (no, I don't really know what's happening here. #TODO learn lambda calculus and explain!)
    ``` cpp
    // A simple generic Y-combinator implementation (C++14/17)
    template<class R, class... Args>
    auto Y = [](auto f) {
        auto action = [=](auto action) -> std::function<R(Args...)> {
            return [=](Args&&... args) -> R {
                // The 'f' is called with a recursive version of itself (action(action))
                return f(action(action), std::forward<Args>(args)...);
            };
        };
        return action(action);
    };

    // Usage with a factorial function "generator"
    auto fact = Y<int, int>([](auto&& self, int val) {
        if (val < 2) {
            return 1;
        }
        return val * self(val - 1);
    });

    std::cout << fact(5); // Output: 120
    ```

But now we can use the `self` parameter as an alias for the lambda object within its scope, allowing for direct recursive calls.

``` cpp
// The 'self' parameter makes the lambda object available inside its body
auto factorial = [](this const auto& self, int n) -> int {
    if (n <= 1) return 1;
    return n * self(n - 1); // Directly call 'self'
};
// Call it normally, no extra arguments needed
static_assert(factorial(5) == 120, "factorial() incorrect"); //

```

Also, deducing `this` is once again a feature that works strongly with C++26 reflection! Deduction directly provides the instance of the object, including its derived type. Reflection will then allow you to introspect that deduced type at compile-time to see its members, methods, and attributes.


## How implemented 

#TODO


## Sources (some)

[https://www.sandordargo.com/blog/2022/02/16/deducing-this-cpp23](https://www.sandordargo.com/blog/2022/02/16/deducing-this-cpp23)

[https://devblogs.microsoft.com/cppblog/cpp23-deducing-this/](https://devblogs.microsoft.com/cppblog/cpp23-deducing-this/)

[https://antonkw.github.io/scala/y-combinator/](https://antonkw.github.io/scala/y-combinator/)

Deducing <code>this</code> in C++23


# `if consteval`

## `const` syntax timeline:
- `const` original language
- `constexpr` C++11
- `if constexpr` C++17
- `consteval` and `constinit` C++20
- `if consteval` C++23 aka "consteval if", colloquially

## Background & Motivation

`consteval` is an "immediate" function -- every call to it _has to be executed_ during compile time. The `constexpr` keyword indicates the _possibility_ of a function being run at compile-time. If the arguments to a `constexpr` function were all compile-time constants, the compiler _could_ evaluate the `constexpr` function at compile-time, but that would only be a compiler optimization (not required by the language, except in _manifestly constant-evaluated contexts_ that demand a constant expression (e.g. array bound). Here the compiler is required to perform evaluation at compile time). 

So pre C++23, calling `constexpr` from `consteval` does work, but calling `consteval` functions from `constexpr` functions does **not** work. After all, `constexpr` could be evaluated at run time. 

> Using `std::is_constant_evaluated()` also won't work. And we don't expect it to! We use `std::is_constant_evaluated()` in a `constexpr` function to select between a compile-time-friendly implementation and a potentially-faster runtime implementation. Function parameters are not `constexpr`, and using `std::is_constant_evaluated()` within a `constexpr` function doesn't change the overall potential for runtime function execution. The compiler must still be able to generate a valid runtime version of the entire function with all code paths, so this may cause static analysis errors / fail to compile. These failures prevent the possibility of a `consteval` call ending up in runtime code.

* all code examples are currently directly from Sandor Dargo's blog! See [Sources](#sources-some).

``` cpp
consteval int bar(int i) {
    return 2*i;
}

constexpr int foo(int i) {
    if (std::is_constant_evaluated()) {
        return bar(i);
    }
    return 2*i;
}

int main() {
  [[maybe_unused]] auto a = foo(5);
}
/*
main.cpp: In function 'constexpr int foo(int)':
main.cpp:6:14: error: 'is_constant_evaluated' is not a member of 'std'
    6 |     if (std::is_constant_evaluated()) {
      |              ^~~~~~~~~~~~~~~~~~~~~
main.cpp:7:19: error: 'i' is not a constant expression
    7 |         return bar(i);
      |                ~~~^~~

*/
```

## Introducing C++23 `if consteval`!

Enter `if consteval` in C++23! Now we can call `consteval` functions from `constexpr` ones. The syntax looks exactly as we had wanted `if (std::is_constant_evaluated)` to work, but we **can** invoke `consteval` functions if the `if` condition evaluates to `true`, aka when the context is constant-evaluated, but not necessarily explicitly declared so. We continue to safely prevent `consteval` calls ending up in runtime code! (Also, you don't need any header include)

``` cpp
consteval int bar(int i) {
    return 2*i;
}

int foo(int i) {
    if consteval {
        return bar(i);
    }
    return 2*i;
}

int main() {
  [[maybe_unused]] auto a = foo(5);
}
```

## How implemented 

#TODO

## Takeaways

The benefits from unlocking "call-`consteval`-from-`constexpr`" are in line with all motivations for expanding compile-time capabilities:

- We can implement different optimizations for compile time vs. runtime. `if consteval` allows the compiler to choose between a slow but simple-to-implement `constexpr` compile-time version, or a highly optimized (maybe assembly-level) runtime version.
- We can access compile-time library features (e.g. `std::source_location::current()`) when available during constant evaluation, while providing a fallback (or simply doing nothing) at runtime.
- We can use `if consteval` to wrap compile-time assertions (`static_assert`) or other static analysis code that should only be checked during compilation.
- In certain scenarios, we can generate and populate data structures or lookup tables entirely at compile time, avoiding runtime overhead.

We should point out the difference between C++23 `if consteval` and C++17 `if constexpr`. `if constexpr` is a compile-time conditional that causes the compiler to discard branches of code at compilation based on a `constexpr`. This differs from a regular `if` statement, where both branches are compiled, and the condition is evaluated at runtime. `if constexpr` is primarily used in generic template programming and largely supplants SFINAE/manual template specialization, where different code paths may be required based on the properties of a template type (e.g., using type traits like `std::is_integral_v`). And in fact C++26 reflection in concert with `if constexpr` vastly expands our compile-time and metaprogramming toolboxes.

## Sources (some)
[https://www.sandordargo.com/blog/2022/06/01/cpp23-if-consteval](https://www.sandordargo.com/blog/2022/06/01/cpp23-if-consteval)

abelianpi

Filter by Topic

Pattern Matching

Design Patterns in Modern C++20

CppOnline26 Quiz Hunt

Deducing `this` in C++23

Understanding C++23 `if consteval`

Filter by Topic

Pattern Matching

Design Patterns in Modern C++20

CppOnline26 Quiz Hunt

Deducing this in C++23

Understanding C++23 if consteval

Deducing `this` in C++23

Understanding C++23 `if consteval`