if/switch with Initializer (C++17)

Overview

C++17 extended if and switch to accept an optional init-statement before the condition, following the same grammar as the first clause of a C-style for loop. The result is a variable whose lifetime ends at the closing brace of the else branch — not at the end of the enclosing function or block.

This closes a long-standing ergonomic gap. Before C++17, any variable needed only to drive a condition polluted the surrounding scope, requiring either a naked extra brace pair or a resigned acceptance that the variable would linger. The three concrete problems this solves:

• Scope leakage — iterators, lock guards, and error codes surviving past their useful lifetime
• Distance — the preparatory declaration appearing several lines above the condition that tests it
• Accidental reuse — using an end-iterator or a moved-from value after the block, with no compiler help

Syntax

// Grammar: if ( init-statement ; condition )
if (auto it = m.find(k); it != m.end()) { ... }

// Both branches see the init variable; neither the enclosing scope
if (int fd = ::open(path, O_RDONLY); fd >= 0) {
    // fd in scope
} else {
    // fd also in scope here — still holds the negative return value
}
// fd NOT in scope here

// switch follows the same pattern
switch (Result r = compute(); r.status) { ... }
// r NOT in scope after the switch

// if constexpr also accepts an init-statement (C++17)
// The condition must still be a compile-time constant expression
if constexpr (constexpr int n = Traits<T>::arity; n > 0) { ... }

The init-statement may be any simple-declaration (including structured bindings) or expression statement. It ends at the semicolon; everything between the semicolon and the closing parenthesis is the condition.

Examples

Map lookup

std::unordered_map<std::string, Config> registry;

if (const auto it = registry.find(name); it != registry.end()) {
    apply(it->second);
} else {
    // it is valid here — it == registry.end()
    load_default(name);
}
// it no longer exists; no risk of stale iterator reuse

Insert-or-update with structured bindings (C++17)

// emplace returns pair<iterator, bool>; structured binding unpacks it inline
if (auto [it, inserted] = table.emplace(user_id, Record{}); inserted) {
    it->second.created_at = now();
} else {
    it->second.last_seen = now();
}

Before C++17, the pair had to be named in the enclosing scope, or the code required a nested block to constrain its lifetime.

RAII lock guard

std::mutex mu;
Cache cache;

if (std::lock_guard lock{mu}; cache.has(key)) {   // C++17 CTAD for lock_guard
    return cache.get(key);
}
// lock released here whether the branch was taken or not

// Pre-C++17 equivalent — extra braces required:
{
    std::lock_guard<std::mutex> lock{mu};
    if (cache.has(key)) return cache.get(key);
}

The init-statement acquires the RAII guard; the condition tests the protected state. This pattern is idiomatic for any guard whose lifetime should match the conditional block.

File descriptor acquisition

if (int fd = ::open(path, O_RDONLY | O_CLOEXEC); fd >= 0) {
    auto closer = defer([fd]{ ::close(fd); });
    return read_all(fd);
} else {
    throw std::system_error{errno, std::system_category(), path};
}

dynamic_cast guard

void dispatch(Base* b) {
    if (auto* d = dynamic_cast<Derived*>(b); d != nullptr) {
        d->derived_only_method();
    }
    // d does not exist here; can't accidentally use a null pointer outside the guard
}

Storing the cast result above the if would leave a potentially-null Derived* visible to subsequent code.

switch with initializer

enum class Status { OK, Retry, Fatal };
struct Result { Status status; int delay_ms; std::string message; };

switch (Result r = compute(); r.status) {
    case Status::OK:
        commit(r.value);
        break;
    case Status::Retry:
        schedule_retry(r.delay_ms);
        break;
    case Status::Fatal:
        throw std::runtime_error{r.message};
}
// r not in scope here

Range-based for with init-statement (C++20)

C++20 extended the same mechanism to range-based for:

// for ( init-statement ; range-declaration : range-expression )
for (auto data = fetch_batch(); const auto& item : data.items()) {  // C++20
    process(item);
}

// Index counter alongside range-for — avoids polluting outer scope
for (std::size_t i = 0; const auto& elem : container) {   // C++20
    std::println("[{}] {}", i++, elem);
}

Before C++20, the index-counter pattern either required a mutable i in the outer scope or abandoning range-for in favour of a plain indexed loop.

Best Practices

Keep the init-statement a single, obvious acquisition. If setup requires multiple steps, extract a named function and call it in the init. A complicated init-statement degrades readability as much as the scope leakage it was meant to prevent.

Prefer const auto when the initialized value is read-only. Declaring inline makes const correctness easier to enforce than with a pre-declared mutable variable:

if (const auto it = m.find(k); it != m.end()) {
    // it->second is read-only; compiler rejects accidental mutation
}

Use it for every RAII guard whose scope matches a conditional. Any time you write { guard g{...}; if (...) { ... } } solely to control the guard's lifetime, an if-init statement removes the wrapper braces and makes the relationship between acquisition and condition explicit.

Avoid if-init when the variable must survive the block. If you need to inspect the result after the else, a conventional declaration is the right choice. Forcing a post-block use would require hoisting the variable anyway.

Common Pitfalls

The variable is in scope in the else branch. This is by design — the else is logically part of the same conditional — but it surprises programmers who expect init-scope to mirror if-scope:

if (auto it = m.find(k); it != m.end()) {
    use(*it);
} else {
    // it is valid here and equals m.end()
    // Not "gone" — just pointing past the end
}

Omitting the semicolon changes semantics entirely. Without the semicolon, the expression becomes the condition itself, relying on implicit bool conversion rather than the intended check:

if (auto it = m.find(k))            // condition: bool(it) — always true for a valid iterator
if (auto it = m.find(k); it != m.end())  // correct: init + explicit condition

This compiles silently in both forms, so the mistake isn't caught until the logic is wrong at runtime.

if constexpr with an init-statement still requires a compile-time condition. The init may compute a value, but the condition must be a constant expression. A runtime value in the condition position is an error:

template <typename T>
void f(T x) {
    if constexpr (constexpr auto n = sizeof(T); n > 4) { ... }  // OK: sizeof is constexpr
    if constexpr (auto n = x.size(); n > 4) { ... }             // error: n is not constexpr
}

Structured bindings in if-init require C++17. Both features arrived in C++17, but projects with mixed -std=c++14/-std=c++17 translation units can produce confusing errors if a header uses the combination and is included in a C++14 TU.

Switch with Init-Statement in Depth

The grammar switch (init; condition) is identical to the if form. The init-statement runs once before the switch dispatches on the condition value, and the initialized variable remains in scope for the entire switch body — all cases, including the default.

Status-code dispatch

A common pattern is constructing a result object in the init and switching on one of its fields:

enum class HttpStatus { Ok = 200, NotFound = 404, ServerError = 500 };

struct Response {
    HttpStatus code;
    std::string body;
};

Response fetch(const std::string& url);

switch (Response resp = fetch(url); resp.code) {
    case HttpStatus::Ok:
        process(resp.body);
        break;
    case HttpStatus::NotFound:
        log_missing(url);
        break;
    case HttpStatus::ServerError:
        throw std::runtime_error{"server error: " + resp.body};
    default:
        log_unexpected(static_cast<int>(resp.code));
        break;
}
// resp is destroyed here; its destructor runs before the next statement

Before C++17 the resp variable would either leak into the surrounding scope or require an explicit brace pair around the switch:

// C++14 — resp escapes the switch
Response resp = fetch(url);
switch (resp.code) { ... }
// resp still alive here — unexpected data still accessible

Multi-field objects in the init

Because the init-statement creates a named variable, all of its members are accessible from every case without any additional declarations:

switch (auto conn = db.connect(); conn.state()) {
    case DbState::Open:
        conn.execute(query);
        [[fallthrough]];
    case DbState::Idle:
        conn.ping();
        break;
    case DbState::Error:
        throw DbException{conn.error_message()};
}
// conn.close() runs via RAII destructor

This is impossible with the pre-C++17 single-expression switch (db.connect().state()) — the temporary is destroyed at the semicolon before the first case is reached.

Integer and plain-enum dispatch

The init-statement is equally useful when the condition is a plain integer or unscoped enum, not just a scoped enum class:

switch (int rc = ::write(fd, buf, len); rc < 0 ? -1 : 0) {
    case 0:
        bytes_written += rc;
        break;
    case -1:
        if (errno == EINTR) retry();
        else throw std::system_error{errno, std::system_category()};
        break;
}

Here the init captures the return value, and the condition expression normalises it to a two-value integer that the cases can match exhaustively.

RAII Scope Limiting with If-Init in Depth

The canonical RAII use-case is ensuring a resource guard lives exactly as long as the condition and the branch that uses it. If-init makes this relationship structural rather than relying on brace discipline.

Precise lock scope

std::mutex mu;
std::unordered_map<std::string, int> shared_map;

// Lock is held only for the duration of the if-block
if (std::lock_guard lock{mu}; shared_map.count(key) > 0) {
    return shared_map[key];   // lock released on this return
}
// lock released here if count() was zero
// No mutex held during the expensive fallback below
return compute_and_cache(key);

The alternative without if-init requires either a manual unlock before the fallback, a nested lambda, or an outer brace scope that forces the reader to match braces visually:

// C++14 equivalent — easy to accidentally hold the lock too long
std::lock_guard<std::mutex> lock{mu};
if (shared_map.count(key) > 0) {
    return shared_map[key];
}
// lock STILL HELD here — compute_and_cache runs under the lock
return compute_and_cache(key);

Try-lock pattern

std::unique_lock with std::try_to_lock fits naturally in an if-init because the lock may not be acquired, and the condition tests that:

std::mutex mu;

if (std::unique_lock lock{mu, std::try_to_lock}; lock.owns_lock()) {
    update_cache();   // only reached when lock was actually acquired
} else {
    // lock was not acquired; lock is still a valid, unlocked unique_lock
    schedule_retry();
}
// unique_lock destructor is harmless whether or not it owns the lock

Scoped file handle

Any RAII type works, not just mutexes. A file handle wrapper whose destructor calls fclose can be acquired and used within a single if-init:

if (FILE* f = std::fopen(path, "r"); f != nullptr) {
    auto closer = FileCloser{f};   // RAII over the raw FILE*
    parse(f);
} else {
    throw std::ios_base::failure{std::string{"cannot open "} + path};
}
// f is out of scope; no risk of a dangling fclose() call later

Why not unique_ptr as the init?

unique_ptr works but produces verbose syntax because the condition must repeat the pointer name:

if (auto p = std::make_unique<Widget>(args); p) {
    p->run();
}

This is still useful when the factory may return nullptr to signal failure instead of throwing.

Structured Bindings in If-Init in Depth

Structured bindings and if-init-statements are independent C++17 features that compose naturally. The binding unpacks a multi-value return; the init-statement limits that binding's scope to exactly where the values are needed.

map::insert and map::emplace

std::map::insert and std::unordered_map::emplace both return std::pair<iterator, bool>. Without if-init the pair must either be named in the enclosing scope or the bool discarded:

std::map<int, std::string> index;

// C++17: structured binding + if-init — pair is never named, never leaks
if (auto [it, inserted] = index.insert({42, "hello"}); inserted) {
    std::cout << "inserted at key " << it->first << '\n';
} else {
    std::cout << "key already existed, value: " << it->second << '\n';
}
// it and inserted are out of scope here

map::try_emplace for conditional construction

try_emplace only constructs the mapped value when the key is absent, making it efficient for expensive-to-construct values:

if (auto [pos, ok] = cache.try_emplace(key, std::in_place, heavy_args...); ok) {
    pos->second.initialize();   // first-time setup
}
// pos and ok out of scope; iterator not accidentally reused

std::find_if with a predicate

find_if returns a single iterator, but the sentinel comparison is the natural condition:

const std::vector<Record> records = load();

if (auto it = std::find_if(records.begin(), records.end(),
        [&](const Record& r) { return r.id == target_id; });
    it != records.end()) {
    consume(*it);
}

The lambda captures target_id from the enclosing scope; the iterator it itself is scoped to the block.

Error-code structs

Functions that return a struct carrying both a value and a status are common in systems code. Structured bindings let you name both fields immediately; if-init prevents the error-code field from leaking:

struct ParseResult { int value; std::errc ec; };
ParseResult parse_int(std::string_view sv);

if (auto [val, ec] = parse_int(input); ec == std::errc{}) {
    use(val);
} else {
    std::cerr << "parse failed: "
              << std::make_error_code(ec).message() << '\n';
}

std::regex_search

std::smatch is populated as a side-effect of regex_search, making it a natural init-statement target:

const std::regex pattern{R"((\d{4})-(\d{2})-(\d{2}))"};
std::string line;

while (std::getline(stream, line)) {
    if (std::smatch m; std::regex_search(line, m, pattern)) {
        process_date(m[1].str(), m[2].str(), m[3].str());
    }
}

Here m is declared in the if-init (the init-statement is the declaration std::smatch m; with no initializer — a default-constructed object), and the condition is the regex_search call that populates it. This is one of the few cases where the init-statement is a declaration without an initializer; the side-effectful condition does the actual work.

while — No Init-Statement; Use for Instead

Unlike if and switch, the while statement did not receive an init-statement extension in C++17 or C++20. There is no while (init; condition) syntax. Attempting it is a compile error.

When you need a variable scoped to a while loop, the plain for loop already provides a solution:

// NOT valid C++ — while does not accept an init-statement
// while (auto chunk = read_chunk(stream); chunk.size() > 0) { ... }  // error

// Valid: for-loop with an empty increment
for (auto chunk = read_chunk(stream); chunk.size() > 0; chunk = read_chunk(stream)) {
    process(chunk);
}

// Cleaner alternative when re-reading is cheap: assign inside condition
std::vector<char> chunk;
while ((chunk = read_chunk(stream)).size() > 0) {
    process(chunk);
}

The C++20 range-based for with init-statement (covered above) fills a different role: it scopes a helper variable alongside an existing range, rather than driving the iteration condition itself.

Why the asymmetry exists

The original proposal (P0305R1, 2016) deliberately restricted the extension to if and switch. The rationale: for already had an init clause; while can be mechanically converted to for; and adding init-statements to while was seen as providing less marginal value relative to the added grammar complexity.

// These are exactly equivalent in semantics:
for (T x = f(); cond(x); )  { body(x); }   // for with empty increment
// vs. the hypothetical (not valid):
// while (T x = f(); cond(x)) { body(x); }

Prefer the for form; it is idiomatic, universally understood, and does not require rewriting the acquisition expression in two places.

See Also

• Structured Bindings — frequently composed with if-init for decomposing return values
• RAII — if-init as a precise scope delimiter for resource guards
• if constexpr — compile-time branching, also accepts an init-statement