# Issue with Type Inference from default parameters

**URL:** <https://forums.swift.org/t/issue-with-type-inference-from-default-parameters/79751>\
**Category:** Using Swift\
**Tags:** generics, associatedtype\
**Created:** [May 7, 2025, 5:48pm UTC](https://forums.swift.org/t/issue-with-type-inference-from-default-parameters/79751 "2025-05-07T17:48:52Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![couchdeveloper](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/couchdeveloper/32/23601_2.png) [@couchdeveloper](https://forums.swift.org/u/couchdeveloper)\
**Post date:** [May 7, 2025, 5:48pm UTC](https://forums.swift.org/t/issue-with-type-inference-from-default-parameters/79751/1 "2025-05-07T17:48:52Z")

</div>

Since [SE-0347](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0347-type-inference-from-default-exprs.md#type-inference-from-default-expressions) the following will compile as expected:

```swift
func compute<C: Collection>(_ values: C = [0, 1, 2]) { ... } 

```

So, the compiler can successfully infer the type of a generic from a default value expression for the function parameter.

Now I encountered an issue in a more complex case which involves associated type inference where the compiler fails to infer the type and emits an error:

Given a protocol which is later used as a type constraint for that function parameter:

```swift
protocol Subject<Value> {
    associatedtype Value
    func send(_ value: Value)
}

```

and another protocol P with an associated type and a static function where the above protocol is used as the parameter:

```swift
protocol P {
    associatedtype V
    
    static func foo<S: Subject<V>>(subject: S)
}

```

Now I want to have a default implementation of the above static function which also sports a default parameter:

```swift
struct DefaultSubject<Value>: Subject {
    func send(_ value: Value) {}
}

extension P {
    static func foo<S: Subject<V>>(subject: S = DefaultSubject<V>()) {}
}

```

Now, I want to define an Enum type for my use case:

```swift
enum E: P {
    typealias V = Int
}

```

So far so good. The compiler is happy.

But when I try to use it:

```swift
func test() async throws {    
    E.foo(subject: DefaultSubject()) // fine!
    E.foo() // Error: Generic parameter 'S' could not be inferred
}

```

The compiler cannot infer the type in the second line!

My understanding is, when the compiler applies the default parameter it would try something like this:

```swift
    let defaultParam = DefaultSubject<E.V>()
    E.foo(subject: defaultParam)
}

```

which _does_ compile.

It's also my understanding (I could be wrong, though) that for the compiler everything needed to figure out the types should be there.

So, what's going on?  
Do I miss something?  
How can I fix it, or what would be a possible workaround?

> **Copy&Paste Test**
>
> ```swift
> import Testing
> 
> protocol Subject<Value> {
> associatedtype Value
> func send(_ value: Value)
> }
> 
> protocol P {
> associatedtype V
>     
> static func foo<S: Subject<V>>(subject: S)
> }
> 
> struct DefaultSubject<Value>: Subject {
> func send(_ value: Value) {}
> }
> 
> extension P {
> static func foo<S: Subject<V>>(subject: S = DefaultSubject<V>()) {}
> }
> 
> enum E: P {
> typealias V = Int
> }
> 
> @Test func test() async throws {
>     
> E.foo(subject: DefaultSubject()) // fine!
> E.foo() // Generic parameter 'S' could not be inferred
>     
> let defaultParam = DefaultSubject<E.V>()
> E.foo(subject: defaultParam)
> }
> 
> ```

---

<div class="post-metadata">

**Author:** ![couchdeveloper](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/couchdeveloper/32/23601_2.png) [@couchdeveloper](https://forums.swift.org/u/couchdeveloper)\
**Post date:** [May 8, 2025, 6:07am UTC](https://forums.swift.org/t/issue-with-type-inference-from-default-parameters/79751/3 "2025-05-08T06:07:20Z")

</div>

Thank you Danny. I agree with your observation, that using a default expression does not work at all in this scenario.

Currently, I'm working around this issue with using an overload as you suggested. But it becomes quickly cumbersome to define all combinations when you have two or more default expressions, not to mention that the overload should have a documentation as well, resulting in a lot of "boiler plate" with potentially increased maintenance efforts.