DEV Community: Modestas Valauskas

IIFEs are Dart's most underrated feature

Modestas Valauskas — Tue, 27 Jan 2026 14:39:54 +0000

IIFEs in Dart are severely underrated and barely anyone seems to agree with me. This is a hill I'm willing to die on, and I've decided to collect my thoughts into a blog post that will hopefully get you on this hill, too.

IIFE stands for Immediately Invoked Function Expression. What does that even mean? Let's start at the beginning. Bear with me. If you already know what IIFEs are, feel free to skip to the use cases.

Table of contents:

What's an expression? - Immediately Invoked Function Expressions
What's a function? - Immediately Invoked Function Expressions
What's a function expression? - Immediately Invoked Function Expressions
What's an invocation? - Immediately Invoked Function Expressions
What's immediacy? - Immediately Invoked Function Expressions
IIFE use cases
- Dart has no if-expression
- IIFEs reduce mental load by scoping things locally
- Region indicators
- IIFEs give you statements everywhere
- IIFEs can return null in widget lists
- Try-catch as an expression
- Late final with complex initialization
- Null-safe value extraction
- Switch expressions only support expressions
- Debug-only code with assert
Performance
- If-else benchmark
- Switch expression benchmark
- dart2js output
Conclusion

What's an expression?

A programming language consists of different entities of abstraction. An expression is one such entity that fulfills the purpose of describing what values your program is going to produce. Examples include literals like 123 or 'hello', variable references, arithmetic like 1 + 2, and function calls.

What's a function?

A function is a collection of statements (and since expressions can be statements, also a collection of expressions). Functions have a name, parameters, a return type, and a body where statements live:

String greet(String name) {
  123; // expression statement
  final message = 'Hello, $name!'; // expression on the right-hand side
  return message;
}

Here, greet is the name, String name is the parameter, the return type is String, and everything between the curly braces is the body. The body contains three statements: an expression statement (123;), a variable declaration with an expression on the right-hand side, and a return statement.

There are many other places where expressions can exist, but these are the most relevant for now.

What's a function expression?

Dart supports anonymous functions by supporting expressions that are functions. Anonymous means no name, and the return type is implicit, it can't be specified and will be inferred automatically:

final a = () {};

final b = (String name) {
  final message = 'Hello, $name!';
  return message;
};

What's an invocation?

To "invoke" something means essentially to call or execute something.

void main() {
  print("Hello World");
}

In that example, print is a function that was invoked, or in other words, called. You can also be very explicit about calling something in Dart and call the call method of a Function:

void main() {
  print.call("Hello World");
}

Think of calling and invoking something as being one and the same thing.

What's immediacy?

What happens if we immediately invoke (call) a function expression? Let me present to you, an immediately invoked function expression:

void main() {
//vvvvv function expression
  () {}();
  //   ^^ invocation
}

That's an expression that is a function expression that is being invoked directly where it was defined.

Admittedly, this looks weird at first sight, but everything in programming does the first time you see it. The question is: what does it give us? And IIFEs give us a whole lot.

IIFE use cases

There are many common annoyances in Dart that are immediately (no pun intended) solved by using IIFEs.

Dart has no if-expression

Dart only supports if statements. Ternary expressions work for simple cases, but they become unreadable with multiple conditions or when you need to execute statements.

With an IIFE, you get an if-expression:

final result = () {
  if (condition1) {
    return "a";
  } else if (condition2) {
    return "b";
  } else {
    return "c";
  }
}();

This is especially useful when initializing final variables that depend on complex logic.

IIFEs reduce mental load by scoping things locally

Consider:

void foo() {
  // Many lines of unrelated code
  // ...
  () {
    final a = 123;
    final b = "abc";
    // ...
  }();
  // Many lines of other unrelated code
  // ...
}

Anything defined in the IIFE doesn't pollute the namespace that comes after it. Without it, you'd have to be careful not to declare or reuse/overwrite values that have been declared before, and you avoid problems where you accidentally shadow names used elsewhere.

Note: You might wonder why you need the ()() at all. Dart does support plain block statements { ... } for scoping without the function wrapper. But blocks are statements, not expressions, so you can only use them where statements are allowed. IIFEs give you scoping and an expression you can use anywhere.

This, for example, is an invalid program since foo is declared locally, but the intention is to use the global foo:

void foo() {}

void main() {
  final foo = 123;
  print(foo);
  foo(); // Error: 'foo' isn't a function
}

However, this is fine, since foo only exists within the IIFE:

void foo() {}

void main() {
  () {
    final foo = 123;
    print(foo);
  }();
  foo(); // Works: calls the global foo
}

Region indicators

Most IDEs support collapsible regions. IIFEs are a natural way to tell your IDE that you want something to be collapsible.

The markers on the left give you the opportunity to collapse the whole body of a function expression. Why is that useful? If you need to make sense of what's going on in your codebase, it helps to ignore things you've already determined are irrelevant to the problem at hand. Collapsible regions let you do exactly that.

IIFEs give you statements everywhere

For Flutter to be fun, you should know what an IIFE is.

Widget build(BuildContext context) {
  return Column(
    children: [
      () {
        // Complex logic here
        if (isLoading) {
          return CircularProgressIndicator();
        }
        return Text(data);
      }(),
      // More widgets...
    ],
  );
}

Flutter critics tend to complain about deeply nested widget trees. Well, if you use an IIFE, that's no longer a problem. You can always exchange a Flutter widget (which is an expression) for an IIFE, flatten the logic, and return the widget you need.

This also allows you to copy and paste a list of statements into places that support expressions and places that support statements interchangeably.

IIFEs also help reduce widget duplication. If multiple branches of a conditional return the same outer widget, an IIFE lets you factor it out:

// Before: duplicated Card across three branches
if (user.isPremium) {
  return Card(
    elevation: 4,
    margin: EdgeInsets.all(8),
    child: Column(children: [
      Icon(Icons.star, color: user.tier.color),
      Text(user.displayName),
      Text('Member since ${user.joinDate.year}'),
    ]),
  );
} else if (user.isTrialActive) {
  return Card(
    elevation: 4,
    margin: EdgeInsets.all(8),
    child: Column(children: [
      Icon(Icons.hourglass_top),
      Text(user.displayName),
      Text('${user.trialDaysLeft} days left'),
    ]),
  );
} else {
  return Card(
    elevation: 4,
    margin: EdgeInsets.all(8),
    child: Column(children: [
      Icon(Icons.person),
      Text(user.displayName),
      Text('Upgrade to premium'),
    ]),
  );
}

// After: Card and Column factored out with IIFE
Card(
  elevation: 4,
  margin: EdgeInsets.all(8),
  child: Column(
    children: () {
      if (user.isPremium) {
        final memberDuration = DateTime.now().difference(user.joinDate);
        final years = memberDuration.inDays ~/ 365;
        final badge = years >= 5 ? Icons.diamond : Icons.star;
        return [
          Icon(badge, color: user.tier.color),
          Text(user.displayName),
          Text('Member for $years years'),
        ];
      } else if (user.isTrialActive) {
        final daysLeft = user.trialEnd.difference(DateTime.now()).inDays;
        final isUrgent = daysLeft <= 3;
        return [
          Icon(Icons.hourglass_top, color: isUrgent ? Colors.red : null),
          Text(user.displayName),
          Text('$daysLeft days left'),
        ];
      } else {
        return [
          Icon(Icons.person),
          Text(user.displayName),
          Text('Upgrade to premium'),
        ];
      }
    }(),
  ),
)

Yes, you could put the outer widget in a new function, but that adds complexity and increases the mental load. Do you make it public/private? What do you call it? Where do you put it? In my view, having such helper functions is unhelpful since they will only be used in one place. You don't need them at all when you use IIFEs.

IIFEs can return null in widget lists

As u/Dustlay pointed out, IIFEs have an advantage over Builder widgets: they can return null. A WidgetBuilder must return a Widget, so you'd need at least an empty SizedBox(). But in a Row or Column, that empty widget can mess with spacing.

Column(
  children: [
    Text('Header'),
    // Builder can't return null - you'd need SizedBox() which affects spacing
    // Builder(builder: (context) => showExtra ? ExtraWidget() : SizedBox()),

    // IIFE with ?() can return null
    ?() {
      if (!showExtra) return null;
      final data = computeSomething();
      return ExtraWidget(data: data);
    }(),
    Text('Footer'),
  ],
)

The ? is the null-aware expression operator applied to an IIFE. When the IIFE returns null, the element is omitted from the list entirely. No phantom SizedBox taking up space or interfering with MainAxisAlignment.spaceBetween.

Try-catch as an expression

Dart has no try-catch expression. With an IIFE, you can handle errors and return a value in one go:

final config = () {
  try {
    return jsonDecode(configString);
  } catch (e) {
    return defaultConfig;
  }
}();

This is particularly useful for parsing, file operations, or any fallible initialization where you want a guaranteed value.

Late final with complex initialization

When a late final field needs more than a simple expression to initialize:

class DataProcessor {
  late final Map<String, Handler> _handlers = () {
    final map = <String, Handler>{};
    for (final type in supportedTypes) {
      map[type.name] = type.createHandler();
      map['${type.name}_legacy'] = type.createLegacyHandler();
    }
    return map;
  }();
}

The alternative would be initializing in a constructor or a separate method, but the IIFE keeps the initialization logic right where the field is declared.

More advanced: together with late, IIFEs help you define Excel-style data flow graphs inside of classes without having to add a ton of constructor, initialization, or function declaration boilerplate.

Null-safe value extraction

When you need to safely extract a value through multiple nullable layers:

final userName = () {
  final user = response.data?.user;
  if (user == null) return 'Anonymous';
  if (user.displayName?.isNotEmpty == true) {
    return user.displayName!;
  }
  return user.email?.split('@').first ?? 'User ${user.id}';
}();

This is cleaner than deeply nested ternaries or spreading the logic across multiple statements that pollute your scope.

Switch expressions only support expressions

Dart 3's switch expressions have a limitation: each arm can only contain a single expression. You can't execute statements, declare variables, or add debug logging inside a switch arm.

// This doesn't work - statements aren't allowed in switch expressions
final result = switch (status) {
  Status.loading => {
    print('Loading...'); // Error: statements not allowed
    return LoadingWidget();
  },
  Status.error => ErrorWidget(),
  Status.success => SuccessWidget(),
};

IIFEs solve this elegantly:

final result = switch (status) {
  Status.loading => () {
    print('Loading state entered');
    final message = computeLoadingMessage();
    return LoadingWidget(message: message);
  }(),
  Status.error => () {
    logError(status.error);
    return ErrorWidget(retry: handleRetry);
  }(),
  Status.success => SuccessWidget(data: status.data),
};

Without IIFEs, you'd need to extract each complex arm into a separate function, scattering related logic across your codebase. The IIFE keeps everything inline and readable.

Debug-only code with assert

Dart's assert statements are removed entirely in production builds. Since assert takes an expression, you can use an IIFE to run arbitrary debug-only code with zero production overhead. This is a pattern commonly used by Flutter. Thanks to u/SchandalRwartz for pointing this out.

Here's an example from the Flutter engine:

assert(() {
  // In debug mode, register the schedule frame extension.
  developer.registerExtension('ext.ui.window.scheduleFrame', _scheduleFrame);

  // In debug mode, allow shaders to be reinitialized.
  developer.registerExtension('ext.ui.window.reinitializeShader', _reinitializeShader);

  return true;
}());

The IIFE returns true so the assertion passes, but the real purpose is executing the statements inside. In production, the entire assert statement disappears, including the IIFE and all its side effects.

This is useful for debug logging, registering development tools, or running expensive validation that you only want during development.

Performance

A common concern: "Don't IIFEs create overhead?" I analyzed this by examining what both the Dart VM and dart2js produce.

If-else benchmark

void main() {
  for (int i = 0; i < 100000; i++) { getX(); getY(); }
  print('Done warming up');
  final sw1 = Stopwatch()..start();
  for (int i = 0; i < 10000000; i++) { getX(); }
  sw1.stop();
  final sw2 = Stopwatch()..start();
  for (int i = 0; i < 10000000; i++) { getY(); }
  sw2.stop();
  print('IIFE: ${sw1.elapsedMicroseconds}us');
  print('Traditional: ${sw2.elapsedMicroseconds}us');
}

@pragma('vm:never-inline')
int getX() {  // IIFE version
  final result = () {
    if (condition()) { return expensive() * 2; }
    else { return 42; }
  }();
  return result;
}

@pragma('vm:never-inline')
int getY() {  // Traditional version
  final int result;
  if (condition()) { result = expensive() * 2; }
  else { result = 42; }
  return result;
}

@pragma('vm:prefer-inline')
bool condition() => DateTime.now().millisecondsSinceEpoch % 2 == 0;
@pragma('vm:prefer-inline')
int expensive() => DateTime.now().microsecondsSinceEpoch;

Run with dart --print-flow-graph-optimized benchmark.dart to see the optimized IL:

getX (IIFE):

B1[function entry]:2
    CheckStackOverflow:8(stack=0, loop=0)
    v75 <- StaticCall:16( _getCurrentMicros@0150898<0> ) T{int}
    Branch if RelationalOp:12(<, v75 T{_Smi}, v41) T{bool} goto (28, 29)
    ...
    Branch if TestInt(v87, v26) goto (5, 6)
B5[target]:20  // condition() returned true
    v68 <- StaticCall:16( _getCurrentMicros@0150898<0> ) T{int}
    v18 <- BinarySmiOp:24(<<, v68 T{_Smi}, v26) T{_Smi}  // expensive() * 2
    goto B7
B6[target]:30  // condition() returned false
    goto B7
B7[join]:19 pred(B5, B6) {
    v27 <- phi(v18 T{_Smi}, v24 T{_Smi})  // v24 is constant 42
}
    DartReturn:22(v27)

getY (Traditional):

B1[function entry]:2
    CheckStackOverflow:8(stack=0, loop=0)
    v57 <- StaticCall:16( _getCurrentMicros@0150898<0> ) T{int}
    Branch if RelationalOp:12(<, v57 T{_Smi}, v22) T{bool} goto (26, 27)
    ...
    Branch if TestInt(v69, v23) goto (3, 4)
B3[target]:22  // condition() returned true
    v50 <- StaticCall:16( _getCurrentMicros@0150898<0> ) T{int}
    v78 <- BinarySmiOp:26(<<, v50 T{_Smi}, v23) T{_Smi}  // expensive() * 2
    goto B5
B4[target]:28  // condition() returned false
    goto B5
B5[join]:32 pred(B3, B4) {
    v5 <- phi(v78 T{_Smi}, v4)  // v4 is constant 42
}
    DartReturn:40(v5)

The structure is identical. The IIFE is completely inlined with no closure allocation or call overhead.

Switch expression benchmark

enum Status { loading, error, success }

void main() {
  final statuses = [Status.loading, Status.error, Status.success];
  for (int i = 0; i < 100000; i++) {
    getWithIIFE(statuses[i % 3]);
    getTraditional(statuses[i % 3]);
  }
  print('Done warming up');
  final sw1 = Stopwatch()..start();
  for (int i = 0; i < 10000000; i++) { getWithIIFE(statuses[i % 3]); }
  sw1.stop();
  final sw2 = Stopwatch()..start();
  for (int i = 0; i < 10000000; i++) { getTraditional(statuses[i % 3]); }
  sw2.stop();
  print('Switch+IIFE: ${sw1.elapsedMicroseconds}us');
  print('Traditional: ${sw2.elapsedMicroseconds}us');
}

@pragma('vm:never-inline')
String getWithIIFE(Status status) {  // Switch expression with IIFEs
  return switch (status) {
    Status.loading => () {
      final msg = computeMessage('load');
      return 'Loading: $msg';
    }(),
    Status.error => () {
      final code = getErrorCode();
      return 'Error $code: ${computeMessage('err')}';
    }(),
    Status.success => 'OK',
  };
}

@pragma('vm:never-inline')
String getTraditional(Status status) {  // Traditional switch statement
  switch (status) {
    case Status.loading: return 'Loading: ${computeMessage('load')}';
    case Status.error: return 'Error ${getErrorCode()}: ${computeMessage('err')}';
    case Status.success: return 'OK';
  }
}

@pragma('vm:prefer-inline')
String computeMessage(String prefix) => '$prefix-${DateTime.now().millisecond}';
@pragma('vm:prefer-inline')
int getErrorCode() => DateTime.now().second;

The optimized IL for both versions is structurally identical, just like the if-else case. The VM inlines IIFEs in switch expression arms just as effectively.

dart2js output

Compile with dart compile js -O2 -o out.js file.dart and inspect the output:

Traditional version (inlined directly):

// Cleaned up:
getY() {
  var result;
  if (condition()) {
    result = expensive() * 2;
  } else {
    result = 42;
  }
  return result;
}

// Actual minified output:
// cg(){var t,s=A.cb()
// if(A.ak(new A.H(Date.now(),0,!1))>500){Date.now()
// t=0}else t=42
// A.ci("IIFE: "+s+", Traditional: "+t)}

IIFE version (closure as prototype method):

// Cleaned up:
getX() {
  return new A.ai().$0();  // <-- allocates closure, calls $0
}

A.ai.prototype = {
  $0() {
    if (condition()) {
      return expensive() * 2;
    } else {
      return 42;
    }
  }
}

// Actual minified output:
// cb(){return new A.ai().$0()},
// A.ai.prototype={
// $0(){if(A.ak(new A.H(Date.now(),0,!1))>500){Date.now()
// return 0}else return 42},
// $S:0}

The IIFE version has a small overhead: new A.ai().$0() allocates a closure object and calls through $0. However, V8 and other modern JS engines inline these aggressively, so benchmarks show no measurable difference in practice.

Bottom line: IIFEs have zero runtime cost in optimized Dart VM code, and negligible cost in JavaScript. Use them freely.

Conclusion

IIFEs are a simple concept with broad applications. They give you expressions where Dart only offers statements, scoping where Dart gives you a flat namespace, and flexibility where the language is rigid.

The syntax () {}() might look odd at first, but once you internalize it, you'll start seeing opportunities everywhere: that complex ternary that's getting out of hand, that variable leaking into scope where it shouldn't, that widget tree begging for a bit of logic.

Dart 3 added switch expressions and if-case patterns, which cover some of the ground IIFEs used to own. But IIFEs remain more general. They're not a feature the language gave you; they're a pattern that emerges from first principles. And patterns that emerge from first principles tend to stick around.

Give IIFEs a chance. Your code will thank you.

PS: IIFEs emerged as a concept in the JavaScript world (MDN reference) where they are very common. The thing about Dart is that IIFEs are even cleaner than in JS. To use a function expression with a function body, you don't need any function keywords in Dart, they just work. And you can immediately call them without wrapping parentheses. That's actually very cool, and I can't imagine a cleaner syntax for IIFEs than what Dart offers. I'd love to see the Dart community not reinvent the wheel, but actually use the wheel we have, because our wheel is even better.

PPS: IIFEs increase the expressivity of statements and expressions by providing a way to merge them. Let's assume we don't know what IIFEs are and our language consists only of statements and expressions: We can't put arbitrary statements into arbitrary expressions with statements and expressions in our language only. Once we add IIFEs to our vocabulary, we can always put arbitrary statements into arbitrary expressions. Similar to how expression statements allow you to put expressions into statements, IIFEs can be seen as a "Statement Expression" because they allow you to put statements into expressions.

Discuss on Reddit

Originally published at modulovalue.com. Subscribe to get new posts.

Understanding Dart Class Modifiers by Using Lattices

Modestas Valauskas — Fri, 19 Dec 2025 21:50:41 +0000

Dart 3.0 introduced class modifiers, and at first glance, the combinations can feel overwhelming. base, final, interface, mixin. How do they all fit together? What combinations are valid? Which ones are redundant?

It turns out there's an elegant way to understand the entire system: lattice theory.

The Four Capabilities

Every Dart type has some combination of four fundamental capabilities:

Extendable: can be used with extends
Implementable: can be used with implements
Mixinable: can be used with with
Constructable: can be instantiated directly

Each class modifier combination enables or restricts these capabilities. The lattice below shows how all valid combinations relate to each other.

The Class Modifiers Lattice

View full resolution diagram

Reading the Lattice

The lattice flows from bottom to top:

Bottom: Nothing (no capabilities)
Top: mixin class (all four capabilities)

Each arrow represents adding one capability. Follow arrows upward to see how adding capabilities transforms one modifier combination into another.

Color Coding

Node backgrounds:

Yellow: Existed before Dart 3.0
Green: New with class modifiers
Red: Impossible combinations

Arrow colors represent which capability is being added:

Orange: Mixinable
Teal: Extendable
Blue: Implementable
Brown: Constructable

Key Insights

1. `mixin class` is Maximum Capability

A plain mixin class has all four capabilities. It's the most permissive type you can declare. This is why it sits at the top of the lattice.

2. Some Combinations Are Impossible

Notice the red nodes. For example, final base mixin class is impossible because mixin classes must be extendable (that's how mixins work), but final prevents extension.

3. Pre-Dart 3.0 Types Were Limited

The yellow nodes show what existed before: class, abstract class, and mixin. The green nodes are all the new combinations that class modifiers enable.

Practical Examples

// All four capabilities
mixin class A {}

// Remove implementability, must extend, can't just implement
base mixin class B {}

// Remove extendability and mixinability, can only implement
interface class C {}

// Remove everything except constructability
final class D {}

Why Lattices?

Lattices aren't just a visualization trick. They reveal the algebraic structure of the type system. The fact that Dart's class modifiers form a clean lattice means the design is internally consistent. There are no arbitrary restrictions or special cases.

Understanding this structure helps you:

Remember which combinations are valid
Predict what capabilities a type has
Choose the right modifier for your use case

The next time you're unsure which class modifier to use, think about which capabilities you want to allow, and find the corresponding node in the lattice.

Conclusion

Complex systems with many interacting options are hard to reason about. When you have four independent boolean capabilities, you get 2^4 = 16 possible combinations. Trying to understand these combinations through documentation alone quickly becomes overwhelming.

Lattices provide a way to model these combinations visually and algebraically. Instead of memorizing rules, you can see the relationships. Each node is a valid state, each edge is a transition, and the structure itself encodes the constraints.

As a fun aside: this hierarchy is actually a 4-dimensional cube (a tesseract). Each of the four capabilities corresponds to one dimension, and moving along an edge means toggling that capability on or off. But since we can't intuitively grasp 4-dimensional geometric objects (at least I can't, though some claim they can), the lattice representation serves as a more accessible algebraic structure to aid intuition.

PS: To be complete when it comes to class modifiers, we would also have to discuss sealed classes. They don't fit into this system. In my view, they are a separate feature and should be discussed separately.

PPS: Here's the official documentation for class modifiers, the spec, and the officially maintained ANTLR grammar showing the syntax of modifiers.

Originally published on modulovalue.com

DEV Community: Modestas Valauskas

IIFEs are Dart's most underrated feature

What's an expression?

What's a function?

What's a function expression?

What's an invocation?

What's immediacy?

IIFE use cases

Dart has no if-expression

IIFEs reduce mental load by scoping things locally

Region indicators

IIFEs give you statements everywhere

IIFEs can return null in widget lists

Try-catch as an expression

Late final with complex initialization

Null-safe value extraction

Switch expressions only support expressions

Debug-only code with assert

Performance

If-else benchmark

Switch expression benchmark

dart2js output

Conclusion

Understanding Dart Class Modifiers by Using Lattices

The Four Capabilities

The Class Modifiers Lattice

Reading the Lattice

Color Coding

Key Insights

1. mixin class is Maximum Capability

2. Some Combinations Are Impossible

3. Pre-Dart 3.0 Types Were Limited

Practical Examples

Why Lattices?

Conclusion

1. `mixin class` is Maximum Capability