How to Fix “Extra Argument in Call” in Swift

Extra argument in call

Extra argument 'name' in call

What does “Extra argument in call” mean?

Consider this function:

func greet(name: String) { print("Hello \(name)") }

It accepts one parameter.

This call provides two arguments:

greet( name: "Alice", age: 20 )

There is no age parameter, so Swift can report:

Extra argument 'age' in call

How to interpret the diagnostic

If Xcode reports:

Extra argument 'age' in call

the compiler could not find an available function or initializer whose parameter list accepts the supplied age: argument together with the other arguments.

However, that does not always mean age itself is the real problem.

An earlier argument may have the wrong label or type, causing the intended overload to stop matching. Once that happens, a later argument may be reported as extra.

Typical situations where this error appears

• Passing more arguments than a function accepts
• Calling an initializer with too many arguments
• Using the wrong argument label
• Calling an API with an old parameter name
• Changing a custom initializer without updating its call sites
• Passing unsupported arguments to a SwiftUI view
• Assuming a memberwise initializer still exists
• Adding a custom initializer to a struct
• Failing to match any overload
• Using the wrong trailing-closure structure
• Using incorrect multiple trailing-closure labels
• Passing a Binding where a plain value is expected or vice versa
• Using an outdated SDK or package example

Common causes

1. Too many arguments are supplied

func add(_ a: Int, _ b: Int) -> Int { a + b }

let result = add(1, 2, 3)

The function accepts two arguments, not three.

2. An argument label does not exist

func greet(name: String) { }

greet(
name: "Alice",
age: 20
)

3. The external argument label is wrong

For:

func update( _ value: Int, animated: Bool ) { }

the correct call is:

update( 10, animated: true )

The first parameter has no external argument label.

4. The function signature changed

Suppose the old version was:

func save( name: String, age: Int ) { }

but it is now:

func save( name: String ) { }

An old call site still supplying age will fail.

5. The initializer accepts fewer parameters

struct User { let name: String
init(name: String) {
    self.name = name
}

}

let user = User(
name: "Alice",
age: 20
)

6. A memberwise initializer is no longer available as expected

A simple struct may receive a memberwise initializer automatically:

struct User { var name: String var age: Int }

which can normally be called as:

User( name: "Alice", age: 20 )

Custom initializers, access control, and module boundaries can change which initializers are available to a particular call site.

7. A SwiftUI view receives an unsupported argument

struct UserView: View { let name: String
var body: some View {
    Text(name)
}

}

UserView(
name: "Alice",
age: 20
)

UserView has no initializer that accepts age.

8. A custom initializer changed a SwiftUI view’s available initializers

struct UserView: View { let name: String let age: Int
init(name: String) {
    self.name = name
    self.age = 0
}

var body: some View {
    Text(name)
}

}

The call:

UserView( name: "Alice", age: 20 )

does not match the explicitly declared initializer.

9. A default argument is misunderstood

func show( title: String, animated: Bool = true ) { }

Both of these are valid:

show(title: "Hello")

show(
title: "Hello",
animated: false
)

A default value makes an existing parameter optional at the call site; it does not allow arbitrary extra parameters.

10. Arguments are in the wrong order

func create( name: String, age: Int ) { }

The call should follow the declared parameter order:

create( name: "Alice", age: 20 )

11. None of the overloads match

func load(id: Int) { }

func load(name: String) {
}

load(
id: 10,
name: "Alice"
)

There is no overload that accepts both arguments together.

12. A wrong argument type prevents the intended overload from matching

If several overloads exist, one incorrect argument type may eliminate the expected candidate and cause a later argument to be diagnosed as extra.

13. Optional and non-optional types do not match

This usually produces a type-conversion diagnostic, but with overloaded or generic APIs it can contribute to an “Extra argument” message.

14. A SwiftUI Binding mismatch prevents initializer resolution

For example:

@State private var text = ""

TextField(
"Text",
text: text
)

The binding-based initializer expects:

TextField( "Text", text: $text )

15. The trailing closure is attached incorrectly

The non-closure arguments and closure parameters must match the function declaration.

16. Multiple trailing-closure labels are incorrect

When an API accepts several closures, later trailing closures need the labels expected by the declaration.

17. An SDK or package changed its API

A parameter present in an old example may have been renamed or removed.

18. A custom initializer was changed without updating every caller

Large projects may have many stale call sites.

19. An extension initializer is unavailable in the current generic context

Conditional extensions can make an initializer available only for specific generic specializations.

20. The actual error is an earlier argument

Once overload resolution fails, the compiler may highlight a later argument even though the first mismatch occurred earlier in the call.

What to check first

1. Inspect the actual function or initializer signature

If the call is:

User( name: "Alice", age: 20 )

but the available initializer is:

init(name: String)

then age is not accepted.

2. Use Xcode’s definition and Quick Help features

Open the declaration for the function, initializer, or SwiftUI view and verify the parameters available in the SDK or package version your project is actually compiling against.

3. Check arguments before the highlighted argument

For example:

SomeView( title: count, enabled: true )

If title expects String but count is Int, the intended initializer may already have stopped matching before Swift reaches enabled.

Solution 1: Remove the unsupported argument

func greet(name: String) { print(name) }

greet(
name: "Alice"
)

Solution 2: Add the parameter if the data is genuinely required

func greet( name: String, age: Int ) { print("\(name): \(age)") }

greet(
name: "Alice",
age: 20
)

Solution 3: Correct the argument label

func update( _ value: Int, animated: Bool ) { }

update(
10,
animated: true
)

Solution 4: Distinguish external labels from parameter names

func move( from start: Int, to end: Int ) { }

move(
from: 1,
to: 10
)

The call uses from: and to:, not start: and end:.

Solution 5: Match the initializer declaration

struct User { let name: String
init(name: String) {
    self.name = name
}

}

let user = User(
name: "Alice"
)

Solution 6: Add the missing initializer parameters when needed

struct User { let name: String let age: Int
init(
    name: String,
    age: Int
) {
    self.name = name
    self.age = age
}

}

let user = User(
name: "Alice",
age: 20
)

Solution 7: Verify the struct’s available memberwise initializer

struct User { var name: String var age: Int }

A memberwise initializer is generally available in the appropriate scope:

let user = User( name: "Alice", age: 20 )

If Xcode does not offer that initializer, inspect custom initializers and access-control boundaries.

Solution 8: Check custom SwiftUI initializers

struct ProfileView: View { let name: String let age: Int
init(
    name: String,
    age: Int
) {
    self.name = name
    self.age = age
}

var body: some View {
    Text(name)
}

}

Now this call is valid:

ProfileView( name: "Alice", age: 20 )

Solution 9: Match a custom View’s declared properties and initializer

struct UserView: View { let name: String
var body: some View {
    Text(name)
}

}

UserView(
name: "Alice"
)

Do not pass an age, title, or other argument unless an available initializer accepts it.

Solution 10: Pass bindings correctly

struct EditView: View { @Binding var name: String
var body: some View {
    TextField(
        "Name",
        text: $name
    )
}

}

@State private var name = ""

EditView(
name: $name
)

Solution 11: Unwrap optionals when the initializer expects a concrete value

If an initializer expects User but you have User?:

if let user { UserView( user: user ) }

Resolving an earlier type mismatch may also make the apparently extra argument disappear.

Solution 12: Add the overload you actually need

func open( id: Int, name: String ) { }

if your call legitimately needs both values.

Solution 13: Fix argument types

func show( title: String, count: Int ) { }

show(
title: "Items",
count: 10
)

An incorrect earlier type can prevent Swift from matching the intended overload.

Solution 14: Follow the declared parameter order

func register( name: String, email: String, age: Int ) { }

register(
name: "Alice",
email: "alice@example.com",
age: 20
)

Solution 15: Use default arguments correctly

func present( title: String, animated: Bool = true ) { }

present(
title: "Settings"
)

present(
title: "Settings",
animated: false
)

Solution 16: Match a trailing closure to the function declaration

func load( completion: (String) -> Void ) { }

load { value in
print(value)
}

Solution 17: Use correct labels for multiple trailing closures

func perform( success: () -> Void, failure: () -> Void ) { }

perform {
print("Success")
} failure: {
print("Failure")
}

Solution 18: Compare old examples with the current API

An older example might contain:

SomeAPI( value: value, legacyOption: true )

If the current initializer no longer has legacyOption:, the call must be updated.

Use Xcode’s current autocomplete, Quick Help, and declaration information rather than assuming an older sample still matches.

Solution 19: Check conditional extension initializers

extension Box where Value == String { init(text: String) { self.init(value: text) } }

This initializer is available only when the generic constraints are satisfied.

Solution 20: Check access control

Across module boundaries, an initializer may need to be public:

public init( name: String, age: Int ) { self.name = name self.age = age }

If the expected initializer is not visible, Swift may attempt to match a different accessible initializer.

Solution 21: Verify the TextField initializer you are using

@State private var name = ""

TextField(
"Name",
text: $name
)

Make sure every supplied argument belongs to the selected initializer.

Solution 22: Verify Button closure labels and order

Button("Save") { save() }

or:

Button { save() } label: { Text("Save") }

Incorrect closure ordering or labeling can make the initializer impossible to resolve.

Solution 23: Check generic SwiftUI APIs such as NavigationLink

Generic SwiftUI initializers may report an argument as extra when another argument has the wrong value type, binding type, or generic destination type.

Verify every argument, not only the highlighted one.

Solution 24: Reduce the call to its minimum valid form

If this is difficult to diagnose:

CustomView( title: title, count: count, enabled: enabled, user: user )

temporarily reduce the call to the smallest initializer you know exists, then reintroduce parameters according to the declaration.

Solution 25: Let Xcode autocomplete reconstruct the call

Retyping the function or initializer name can reveal the currently available signatures and labels.

This is often faster than manually updating a call copied from an older API version.

Solution 26: Update renamed parameters across the project

If the declaration is now:

func save( username: String )

an old call such as:

save( name: "Alice" )

must be updated.

Xcode Rename refactoring can help keep declarations and call sites consistent.

Solution 27: Review the effect of adding a custom initializer

If the automatic initializer you expected is no longer available, declare the needed initializer explicitly:

struct User { let name: String let age: Int
init(
    name: String,
    age: Int
) {
    self.name = name
    self.age = age
}

}

Solution 28: Check parameters with no external argument label

func multiply( _ a: Int, by b: Int ) -> Int { a * b }

let result = multiply(
5,
by: 3
)

Do not write a: for the first parameter because its external label is _.

Solution 29: Check for same-named types from different modules

If two modules contain types with the same name, you may be calling the initializer of the wrong type.

Qualify the type when necessary:

MyFramework.User( name: "Alice" )

Solution 30: Break complex arguments into intermediate values

Instead of:

CustomView( user: makeUser(response), settings: loadSettings(), enabled: state.isReady, action: { save() } )

use:

let user: User = makeUser(response) let settings: Settings = loadSettings() let enabled: Bool = state.isReady

CustomView(
user: user,
settings: settings,
enabled: enabled,
action: {
save()
}
)

This separates argument-type problems from initializer-matching problems.

If “Extra argument in call” occurs in SwiftUI

SwiftUI often provides several generic initializers, so the error can be caused by more than just too many parameters.

Check these items in order:

1. Inspect the view’s current properties and explicit initializers.
2. Check whether a custom init was added.
3. Verify every argument label.
4. Verify every argument type.
5. Check Binding versus plain values.
6. Check optional versus non-optional values.
7. Check trailing-closure labels.
8. Fix any earlier compiler diagnostic inside the call.

If the error occurs in a custom View

For:

struct ProductView: View { let title: String let price: Int
var body: some View {
    Text(title)
}

}

this is valid:

ProductView( title: "Book", price: 1000 )

This is not:

ProductView( title: "Book", price: 1000, stock: 5 )

because there is no stock parameter.

If the error occurs in an initializer

If the declaration is:

init( title: String, count: Int )

the call should match its labels, order, and types:

SomeType( title: "Hello", count: 10 )

If the error occurs in a function call

For a call like:

save( name: "Alice", age: 20 )

inspect the definition.

If it is:

func save( name: String )

either remove age from the call or add it to the function if the function truly needs it.

If the error starts after an API update

Compare the old and current signatures and look for:

• Removed parameters
• Renamed parameters
• Changed external argument labels
• Consolidated initializers
• Migration from deprecated APIs

Code copied from an older blog post or Q&A may no longer match the version of the SDK or package your project uses.

If there seems to be no extra argument

Check for these less obvious causes:

• An earlier argument has the wrong type
• Optional versus non-optional mismatch
• Binding versus plain value mismatch
• The wrong overload is being considered
• A custom initializer removed the initializer you expected
• An argument label is wrong
• A same-named type from another module is being used
• Generic inference failed earlier in the call

Validate the call from the first argument to the last.

Will Clean Build Folder fix it?

Usually not.

“Extra argument in call” is normally caused by a mismatch between source code and an available function or initializer signature.

Cleaning:

Product → Clean Build Folder

can occasionally help if Xcode’s index is stale after a large refactor, but it cannot make an invalid call match an initializer that does not accept those arguments.

What you should avoid

The function may actually need that information, in which case the declaration should be updated instead.

Likewise, an earlier type mismatch may prevent the intended overload from matching, making a later argument appear extra even though the overall argument list is conceptually correct.

First identify exactly which function or initializer you intend to call, then make the call site match that signature.

Fast troubleshooting checklist

1. Open the function or initializer definition.
2. Compare argument count with parameter count.
3. Check every argument label.
4. Distinguish external labels from parameter names.
5. Verify argument order.
6. Verify every argument type.
7. Check optional versus non-optional values.
8. In SwiftUI, check Binding versus plain values.
9. Review recently added custom initializers.
10. Check whether the expected memberwise initializer is available.
11. Inspect all overload candidates.
12. Check trailing-closure labels.
13. Verify whether an SDK or package update changed the signature.
14. Inspect arguments before the one Xcode marks as extra.
15. Reduce complex calls to a minimal valid form when necessary.

Summary

Swift’s “Extra argument in call” error means that the arguments at a call site do not match any currently available function or initializer signature.

The cause may be a genuinely extra argument, but it can also be an incorrect argument label, wrong argument order or type, optional mismatch, Binding mismatch, unavailable overload, custom initializer, or changed SDK API.

Start by opening the actual function or initializer declaration and compare its parameter count, labels, order, and types against the call site.

Remove unsupported arguments when they are genuinely unnecessary, or add the corresponding parameters to the function or initializer when the data is required.

For SwiftUI, pay particular attention to custom view initializers, property wrappers, bindings, optionals, and trailing closures. After SDK or package updates, rely on the current API signature rather than older sample code.