Introduction

This Swift error usually is not a URLSession bug. It means the compiler cannot decide which overloaded dataTask method you intended to call, usually because the request value or closure type is too ambiguous. The fix is to make the input type explicit enough that Swift can select the correct overload.

Why the Call Becomes Ambiguous

URLSession has several overloads for dataTask, including versions that accept:

• 'URL'
• 'URLRequest'
• different completion-handler signatures

If Swift cannot tell whether the thing you passed is a URL or a URLRequest, or if optional typing muddies the call, the compiler reports an ambiguous reference.

A Clear Working Example

The safest pattern is to unwrap the URL first and then call the URL overload directly:

1import Foundation
2
3let url = URL(string: "https://example.com/data.json")!
4
5let task = URLSession.shared.dataTask(with: url) { data, response, error in
6    if let error = error {
7        print("request failed:", error)
8        return
9    }
10
11    print("bytes:", data?.count ?? 0)
12}
13
14task.resume()

Because url is explicitly a non-optional URL, Swift can choose the right overload without guessing.

Be Explicit with URLRequest Too

If you need headers, method, or body, use URLRequest and keep the type obvious:

1import Foundation
2
3let url = URL(string: "https://example.com/items")!
4var request = URLRequest(url: url)
5request.httpMethod = "GET"
6
7let task = URLSession.shared.dataTask(with: request) { data, response, error in
8    if let error = error {
9        print("request failed:", error)
10        return
11    }
12
13    print(response as Any)
14}
15
16task.resume()

Again, the critical part is that request is clearly a URLRequest, not something Swift has to infer from a complicated expression.

Common Sources of Ambiguity

A very common problem is optional chaining or weak typing:

1let maybeURL = URL(string: someString)
2URLSession.shared.dataTask(with: maybeURL) { data, response, error in
3    print(data as Any)
4}

That fails because maybeURL is a URL?, not a URL. Unwrap it first:

1if let url = URL(string: someString) {
2    URLSession.shared.dataTask(with: url) { data, response, error in
3        print(data as Any)
4    }.resume()
5}

Another source of ambiguity is passing values typed as Any, AnyObject, or loosely inferred intermediate variables. In overloaded APIs, vague types make the compiler’s job much harder.

Closure Signature Still Matters

The completion handler must also match the expected signature. If you write a closure whose parameters do not line up with the dataTask overload you meant, the compiler can also get confused.

Sticking to the standard form helps:

{ data, response, error in
    // handle result
}

If you are splitting the closure into a named variable, give that variable an explicit type so Swift does not have to infer everything at once.

This Is Usually a Type Problem, Not a Runtime Problem

Because the error happens at compile time, the fix is almost always:

• make the URL non-optional before the call
• make the request type explicit
• simplify the expression so overload resolution is obvious

Once the compiler can see the intended types clearly, the error usually disappears without any workaround.

Common Pitfalls

The most common mistake is passing an optional URL? directly into dataTask. The session APIs expect a concrete URL or URLRequest, not an optional wrapper.

Another pitfall is building the request inline with so much inference that the compiler sees multiple possible overload matches. Breaking the code into named, explicitly typed variables usually fixes it immediately.

It is also easy to assume the API is broken because the error text mentions ambiguity in a scary way. In practice, this is almost always a typing issue in the call site, not a Foundation bug.

Finally, avoid carrying request values around as Any or AnyObject. Overloaded APIs and erased types are a bad combination in Swift.

Summary

• The error means Swift cannot choose the correct dataTask overload from the types you provided.
• Unwrap URL? values before calling dataTask.
• Use explicit URL or URLRequest variables to simplify overload resolution.
• Keep the completion-handler signature standard and unambiguous.
• This is usually a compile-time typing issue, not a real URLSession bug.