Introduction

The Swift warning "Result of call is unused" means a function returned something and your code ignored it. Sometimes that is harmless, but often it reveals the real mistake: calling a non-mutating API when you expected a side effect, or forgetting to store a transformed value.

Why Swift warns about unused results

Swift treats a return value as part of the API contract. If a function returns something, the compiler assumes that result might matter.

For example:

let numbers = [1, 2, 3]
numbers.map { $0 * 2 }   // warning

map builds a new array. Because the result is ignored, the code probably does not do what the programmer intended.

This warning is valuable because it catches logic bugs that would otherwise compile quietly.

Use the returned value when the API is transformational

Many Swift methods return a new value instead of changing the original instance. When that is the case, the fix is to capture the result.

let numbers = [1, 2, 3]
let doubled = numbers.map { $0 * 2 }
print(doubled)

Strings are another common example:

var text = "hello"
text.uppercased()   // warning
print(text)         // still "hello"

The correct version is:

var text = "hello"
text = text.uppercased()
print(text)

The warning is really pointing out the difference between "returns a new value" and "mutates in place."

Choose the API that matches your intent

A lot of these warnings come from using transformation APIs for side effects.

Incorrect:

[1, 2, 3].map { print($0) }

Better:

[1, 2, 3].forEach { print($0) }

map means "transform this collection into another collection." forEach means "visit each element for its side effect." Choosing the right method removes the warning and makes the code’s intent clearer.

Ignore the result explicitly when that is intentional

Sometimes the function returns something, but your code genuinely does not care. In that case, assign the result to _ explicitly.

_ = someFunctionThatReturnsABool()

This silences the warning and documents that discarding the return value was deliberate rather than accidental.

Use this sparingly. If the return value indicates failure, state, or transformed data, ignoring it may still be a bug.

Use @discardableResult for your own APIs

If you own the function and it is reasonable for callers to ignore its result, mark it with @discardableResult.

1@discardableResult
2func logMessage(_ text: String) -> Bool {
3    print(text)
4    return true
5}
6
7logMessage("Started")

This is appropriate when the function’s main purpose is its side effect and the returned value is just extra convenience.

Do not use @discardableResult as a blanket fix for noisy warnings. It weakens the contract of the API and can hide real mistakes.

How to debug the warning quickly

When you see this message, ask:

1. Does this method mutate the receiver or return a new value
2. Should I store, return, or print the result
3. Am I using a side-effect API for a transformation problem, or the reverse
4. If I own the function, is ignoring the result actually valid

Those questions usually reveal the fix immediately.

Common Pitfalls

The most common mistake is silencing the warning with _ = before understanding whether the value matters. That hides the symptom without solving the bug.

Another issue is assuming Foundation and Swift standard-library methods mutate by default. Many of them return new values, and ignoring those new values leaves the original data unchanged.

Developers also misuse map for looping and side effects. The code compiles, but the warning is telling you the method choice is wrong.

Finally, overusing @discardableResult on your own APIs can make later mistakes harder to catch. Apply it only when discarded results are genuinely acceptable.

Summary

• The warning means a function returned something and your code ignored it.
• The usual fix is to capture or otherwise use the returned value.
• Many warnings come from confusing non-mutating methods with mutating ones.
• Use _ = only when discarding the result is truly intentional.
• '@discardableResult is appropriate for side-effect-driven APIs you own, not as a general warning suppressor.'