C++20 Concepts — Why std::list Fails Your Range Constraint

#include <concepts>
#include <iostream>
#include <string>
#include <vector>

// --- Defining a simple concept using a requires expression ---
// The requires expression checks that:
//   1. T has a .size() member returning something convertible to std::size_t
//   2. T supports the subscript operator [] with an integral index
//   3. T is default-constructible
template <typename T>
concept Sequence = requires(T container, std::size_t index) {
    { container.size() } -> std::convertible_to<std::size_t>; // return-type constraint
    { container[index] };                                       // simple validity check
    T{};                                                        // nested requirement: must default-construct
};

// --- A more refined concept that builds ON Sequence ---
// Because SortableSequence requires Sequence AND ordering, it SUBSUMES Sequence.
// The compiler will prefer SortableSequence overloads over plain Sequence overloads.
template <typename T>
concept SortableSequence = Sequence<T> && requires(T container, std::size_t i) {
    { container[i] < container[i] } -> std::same_as<bool>; // elements must be comparable
};

// --- Function constrained with the plain Sequence concept ---
// This overload is chosen for types satisfying Sequence but NOT SortableSequence.
template <Sequence S>
void describe(const S& container) {
    std::cout << "[Sequence] size = " << container.size() << '\n';
}

// --- More-constrained overload: chosen when SortableSequence is satisfied ---
// Subsumption guarantees no ambiguity — the compiler picks this one for std::vector<int>.
template <SortableSequence S>
void describe(const S& container) {
    std::cout << "[SortableSequence] size = " << container.size()
              << ", first element = " << container[0] << '\n';
}

int main() {
    std::vector<int> numbers = {42, 7, 19};
    describe(numbers); // SortableSequence overload wins — int supports operator<

    // std::string satisfies Sequence (has size(), operator[]) AND SortableSequence
    // because char supports operator<
    std::string greeting = "hello";
    describe(greeting);

    // Static assertion: document assumptions directly in code
    static_assert(Sequence<std::vector<int>>,
        "vector<int> must satisfy Sequence");
    static_assert(SortableSequence<std::vector<int>>,
        "vector<int> must satisfy SortableSequence");

    return 0;
}

#include <concepts>
#include <iostream>
#include <numeric>
#include <vector>

// FORM 1: Terse syntax — concept name replaces 'typename' in template parameter
// Best for: single-type constraints, maximum readability
template <std::integral IntegerType>
IntegerType square(IntegerType value) {
    return value * value; // only compiles for int, long, char, etc.
}

// FORM 2: requires clause after template parameter list
// Best for: multi-parameter constraints or compound conditions
template <typename ElementType, typename ContainerType>
    requires std::same_as<typename ContainerType::value_type, ElementType>
          && std::default_initializable<ElementType>
ElementType sum_container(const ContainerType& container) {
    // Guaranteed: ElementType IS the container's element type AND is default-constructible
    ElementType total{}; // default-initialise to zero (works for int, double, etc.)
    for (const auto& element : container) {
        total += element;
    }
    return total;
}

// FORM 3: Trailing requires clause — after the function parameter list
// Best for: constraints that reference parameter types computed from the signature
template <typename Callable, typename ArgumentType>
auto invoke_and_print(Callable&& function, ArgumentType argument)
    -> decltype(function(argument))
    requires std::invocable<Callable, ArgumentType> // constraint reads naturally here
{
    auto result = function(argument);
    std::cout << "Result: " << result << '\n';
    return result;
}

// FORM 4: Abbreviated function template with concept-constrained auto
// Best for: short utility lambdas and simple free functions
// 'std::floating_point auto' means: deduce the type, but it MUST satisfy floating_point
void print_precision(std::floating_point auto value) {
    std::cout << "Floating value: " << value << '\n';
}

int main() {
    // Form 1 — works with int, long; would fail for float (not integral)
    std::cout << "4 squared = " << square(4) << '\n';
    std::cout << "7L squared = " << square(7L) << '\n';

    // Form 2 — sums a vector<double>
    std::vector<double> prices = {9.99, 4.50, 12.75};
    std::cout << "Total price = " << sum_container<double>(prices) << '\n';

    // Form 3 — invokes a lambda and prints the result
    auto doubler = [](int n) { return n * 2; };
    invoke_and_print(doubler, 21); // prints 42

    // Form 4 — works for float and double; fails for int (not floating_point)
    print_precision(3.14159f);
    print_precision(2.71828);

    // Uncommenting the line below gives a clean diagnostic:
    // square(3.14); // error: '3.14' does not satisfy 'std::integral'

    return 0;
}

#include <concepts>
#include <iostream>
#include <iterator>
#include <vector>
#include <list>

// --- Concept hierarchy for iterators ---
// InputIterable: can be iterated forward (covers list, vector, etc.)
template <typename Container>
concept InputIterable = requires(Container c) {
    { std::begin(c) } -> std::input_iterator;
    { std::end(c) };
};

// RandomAccessIterable: subsumes InputIterable because it requires it PLUS random access.
// This is the key: we REFERENCE InputIterable by name so subsumption works.
template <typename Container>
concept RandomAccessIterable = InputIterable<Container> && requires(Container c, std::size_t n) {
    { c[n] };                                           // random access by index
    { std::end(c) - std::begin(c) } -> std::integral; // distance is O(1)
};

// --- Overload for any input-iterable container (less constrained) ---
// Chosen for std::list, where random access doesn't exist
template <InputIterable Container>
void process(const Container& container) {
    std::cout << "[InputIterable path] linear scan, size computed by traversal\n";
    std::size_t count = 0;
    for (const auto& element : container) { ++count; (void)element; }
    std::cout << "  Element count: " << count << '\n';
}

// --- Overload for random-access containers (more constrained) ---
// Compiler picks THIS one for std::vector — subsumption guarantees no ambiguity.
template <RandomAccessIterable Container>
void process(const Container& container) {
    std::cout << "[RandomAccessIterable path] O(1) size, direct index access\n";
    // Safe to use operator[] because the concept guarantees it
    std::cout << "  First element: " << container[0] << '\n';
    std::cout << "  Size (O1): " << (std::end(container) - std::begin(container)) << '\n';
}

// --- WRONG WAY: inline requires instead of concept name breaks subsumption ---
// If you write the same constraint inline in both overloads, you get:
//   error: call to 'process_wrong' is ambiguous
// because the compiler sees two different atomic constraints that happen to say the same thing.
template <typename T>
    requires requires(T c) { std::begin(c); }  // raw inline — NOT a named concept
void process_wrong(const T& container) { std::cout << "overload A\n"; }

// This overload cannot subsume the one above because neither references the other by name
template <typename T>
    requires requires(T c) { std::begin(c); } && requires(T c, int n) { c[n]; }
void process_wrong(const T& container) { std::cout << "overload B\n"; }

int main() {
    std::vector<int> scores = {10, 20, 30};
    std::list<int>   tasks  = {1, 2, 3};

    process(scores); // RandomAccessIterable wins — subsumption at work
    process(tasks);  // Only InputIterable matches — list has no operator[]

    // Uncommenting this causes ambiguity error — inline requires breaks subsumption:
    // process_wrong(scores);

    return 0;
}

#include <concepts>
#include <iostream>
#include <memory>
#include <string>
#include <vector>

// --- Concept for types that can represent a monetary amount ---
template <typename T>
concept MonetaryType = std::floating_point<T> || std::integral<T>;

// --- Class template constrained at the class level ---
// The entire class only exists for MonetaryType parameters
template <MonetaryType CurrencyType>
class Wallet {
    CurrencyType balance_;

public:
    explicit Wallet(CurrencyType initial_balance)
        : balance_{initial_balance} {}

    void deposit(CurrencyType amount) {
        balance_ += amount;
    }

    // Member function with its OWN additional constraint
    // Only available when CurrencyType supports division (i.e., floating point)
    // This gives us Rust-style conditional method exposure
    CurrencyType split_evenly(int ways) const
        requires std::floating_point<CurrencyType> // narrower than the class constraint
    {
        return balance_ / static_cast<CurrencyType>(ways);
    }

    CurrencyType balance() const { return balance_; }
};

// --- Concept-constrained generic lambda (C++20) ---
// This is the replacement for the old unconstrained [](auto x) lambdas
auto format_currency = [](MonetaryType auto amount, const std::string& symbol) {
    std::cout << symbol << amount << '\n';
};

// --- SFINAE to Concepts migration example ---
// OLD (SFINAE style — ugly, opaque):
template <typename T, std::enable_if_t<std::is_arithmetic_v<T>, int> = 0>
T sfinae_double(T value) { return value * 2; }

// NEW (Concepts style — readable, better diagnostics, same semantics):
template <typename T>
    requires std::is_arithmetic_v<T> // can use type traits directly in requires
T concept_double(T value) { return value * 2; }

// EVEN BETTER — name the concept for reuse and subsumption:
template <typename T>
concept Arithmetic = std::is_arithmetic_v<T>;

template <Arithmetic T>
T named_concept_double(T value) { return value * 2; }

// --- Concept-constrained lambda for use with standard algorithms ---
// Ensures the comparator actually returns bool — catches custom Compare objects that don't
auto make_descending_comparator = []<std::totally_ordered ElementType>() {
    return [](const ElementType& lhs, const ElementType& rhs) {
        return lhs > rhs; // descending order
    };
};

int main() {
    // Class template usage
    Wallet<double> savings{1000.0};
    savings.deposit(250.50);
    std::cout << "Balance: " << savings.balance() << '\n';
    std::cout << "Split 3 ways: " << savings.split_evenly(3) << '\n';

    // Wallet<int> integer_wallet{500};
    // integer_wallet.split_evenly(3); // compile error: constraint not satisfied
    //   'split_evenly' requires floating_point<int> which is false

    // Concept-constrained lambda
    format_currency(99.95, "$");
    format_currency(150, "€"); // int satisfies MonetaryType (integral branch)

    // SFINAE vs Concepts — same behaviour, dramatically different readability
    std::cout << sfinae_double(21)     << '\n'; // 42
    std::cout << concept_double(21)    << '\n'; // 42
    std::cout << named_concept_double(21) << '\n'; // 42

    // Constrained lambda producing a type-safe comparator
    auto int_desc = make_descending_comparator.operator()<int>();
    std::vector<int> values = {3, 1, 4, 1, 5};
    std::sort(values.begin(), values.end(), int_desc);
    for (int v : values) std::cout << v << ' ';
    std::cout << '\n';

    return 0;
}

#include <concepts>
#include <iostream>
#include <vector>
#include <list>

// --- GOOD: Minimal concept that composes well ---
// A Printable type can be sent to an output stream via operator<<
template <typename T>
concept Printable = requires(std::ostream& os, T value) {
    { os << value } -> std::same_as<std::ostream&>;
};

// --- GOOD: Composable refinement ---
// A Loggable type is Printable AND has a name() function returning a string
template <typename T>
concept Loggable = Printable<T> && requires(T obj) {
    { obj.name() } -> std::convertible_to<std::string_view>;
};

// --- BAD: Over-constrained concept that excludes valid types ---
// This requires T to have a non-const operator[] returning an lvalue reference to exactly int.
template <typename T>
concept TooStrict = requires(T c, std::size_t i) {
    { c[i] } -> std::same_as<int&>; // fails for std::vector<bool> which returns proxy
};

// --- BETTER: Use convertible_to for return-type constraints ---
template <typename T>
concept IndexableToInt = requires(T c, std::size_t i) {
    { c[i] } -> std::convertible_to<int>; // accepts proxy types
};

// --- Common gotcha: volatile in requires ---
// If T is volatile int, this concept fails because volatile int cannot bind to int&
template <typename T>
concept Writable = requires(T& obj) {
    obj = T{};
};

// Workaround: use std::remove_cvref_t to strip volatile before checking
template <typename T>
concept WritableBetter = requires(std::remove_cvref_t<T>& obj) {
    obj = T{};
};

// --- Usage example with static_assert ---
struct Account {
    std::string name() const { return "account"; }
    friend std::ostream& operator<<(std::ostream& os, const Account& a) {
        return os << a.name();
    }
};

int main() {
    static_assert(Printable<int>);
    static_assert(!Printable<std::vector<int>>); // no operator<< defined
    static_assert(Loggable<Account>);
    static_assert(IndexableToInt<std::vector<int>>);
    static_assert(!IndexableToInt<std::list<int>>); // no operator[]
    
    std::cout << "All concept checks passed.\n";
    return 0;
}