Q: What does it give you in practice that functions are first-class values?

Answer with concrete patterns rather than a theoretical definition. Passing a strategy: List.sort((a, b) => ...), where, map — behaviour travels as a parameter, so no class hierarchy is needed. Dependency inversion: I pass a repository a Future Function(String url) get and hand it a fake function in tests — isolation without a mocking library. Higher-order utilities: withRetry(fn, times) closes over the original function and returns a new one; the same pattern covers logging and caching wrappers. Factory plus closure: building a client that captures its configuration once. Finish with a note on type safety: I always write the full signature (bool Function(User)) and treat bare Function as banned because it loses checking, and I name repeated signatures with a typedef.

Question 1

What is the difference between positional, optional positional and named parameters in Dart? When do you pick which?

Accepted Answer

Start by showing the syntax briefly: f(a, b), f(a, [b = 0]), f({required a, b = 0}). Then give two technical rules — [] and {} cannot appear in the same signature, and a non-nullable named parameter with no default must be required. The most valuable part is the selection criterion: positional for one or two obvious arguments (substring(0, 5)); named for three or more, especially with bool flags — upload(true, false) is unreadable while upload(compress: true, overwrite: false) reads itself. I almost never choose optional positional in practice: adding a parameter later disturbs the order, whereas named lets you extend the API backwards-compatibly. Pointing at Flutter APIs, which are almost entirely named (Text('a', style: ..., maxLines: ...)), strengthens the answer.

Question 2

What is a closure, and which value does a closure created inside a loop capture in Dart?

Accepted Answer

Start with the definition: "A closure is a function plus the lexical environment it was created in; it keeps access to outer-scope variables even after that scope has finished." Then the crucial refinement: a Dart closure captures the variable's binding, not a copy of the value. Move to the loop question and answer both halves: for (var i = 0; i < 3; i++) creates a fresh binding per iteration, so the result is 0, 1, 2; if the variable is declared outside the loop (var i; for (i = 0; ...)) there is a single binding and the result is 3, 3, 3. Add that this mirrors the var/let distinction in JavaScript, except Dart gives you the "correct" behaviour by default. Finish with the practical consequence: a closure keeps the captured object alive, so a callback capturing this in a long-lived listener can leak memory and the subscription must be cancelled in dispose().

Question 3

What does it give you in practice that functions are first-class values?

Accepted Answer

Answer with concrete patterns rather than a theoretical definition. Passing a strategy: List.sort((a, b) => ...), where, map — behaviour travels as a parameter, so no class hierarchy is needed. Dependency inversion: I pass a repository a Future<Response> Function(String url) get and hand it a fake function in tests — isolation without a mocking library. Higher-order utilities: withRetry(fn, times) closes over the original function and returns a new one; the same pattern covers logging and caching wrappers. Factory plus closure: building a client that captures its configuration once. Finish with a note on type safety: I always write the full signature (bool Function(User)) and treat bare Function as banned because it loses checking, and I name repeated signatures with a typedef.

Question 4

How do you detect and prevent a memory leak caused by a closure?

Accepted Answer

Start with the mechanism: a closure holds a strong reference to every variable it captures, so a callback registered on a long-lived object (a stream subscription, timer, global event bus) keeps a short-lived object — usually this — alive and unreachable for GC. Prevention: every StreamSubscription, Timer and listener must have a cancellation path called at the end of the owner's life (dispose()); capture only the field you need rather than the whole object (final id = user.id; then () => send(id)); avoid parking callbacks in static or global collections. Detection: in DevTools' Memory view I repeat the same scenario several times and take snapshots; if the instance count grows monotonically I follow the retaining-path tree to find which closure holds the reference. In tests, a cheap and effective check is a unit test asserting the callback is no longer invoked after dispose().

Form	Signature	Call site	When to use
Positional	`f(int a, int b)`	`f(1, 2)`	1-2 obvious arguments
Optional positional	`f(int a, [int b = 0])`	`f(1)` or `f(1, 2)`	Rare; mostly legacy APIs
Named	`f({required int a, int b = 0})`	`f(a: 1, b: 2)`	3+ arguments, boolean flags, config objects

Functions and closures

📚 Sources and documentation