Attachment: Download

Issue Description:

Bumped into on the SwiftNIO 1.4.0 release.

Consider a hypothetical SwiftPM package (a tarball containing a sample package is attached) that has two modules, First and Second. The module Second defines a type called Test with the following definition:

public struct Test {
    public init(vals: [(Bool, Bool)] = []) {
        print("Initialized with one argument")
    }
}

The module First defines an extension to Test to conform it to ExpressibleByDictionaryLiteral, and then runs some code:

import Second

extension Test: ExpressibleByDictionaryLiteral {
    public typealias Key = Bool
    public typealias Value = Bool

    public init(dictionaryLiteral: (Bool, Bool)...) {
        print("Initialized by dictionary literal")
        self.init()
    }
}

let t = Test()
print(t)

When compiled and run, this program outputs:

Initialized with one argument
Test()

Imagine, then, that the source code of Second is changed to be this instead:

public struct Test {
    public init(_ vals: [(Bool, Bool)] = [], _ other: Bool = false) {
        print("Initialized with two arguments")
    }
}

When the new program, whose only difference is the addition of an argument with a default value in its only initializer, is compiled and run, the following compile error occurs:

/Users/lukasa/tmp/srrepro/Sources/First/main.swift:13:9: error: ambiguous use of 'init'
let t = Test()
        ^
Second.Test:2:12: note: found this candidate
    public init(_ vals: [(Bool, Bool)] = default, _ other: Bool = default)
           ^
/Users/lukasa/tmp/srrepro/Sources/First/main.swift:7:12: note: found this candidate
    public init(dictionaryLiteral: (Bool, Bool)...) {
           ^
/Users/lukasa/tmp/srrepro/Sources/First/main.swift:9:9: error: ambiguous use of 'init'
        self.init()
        ^
Second.Test:2:12: note: found this candidate
    public init(_ vals: [(Bool, Bool)] = default, _ other: Bool = default)
           ^
/Users/lukasa/tmp/srrepro/Sources/First/main.swift:7:12: note: found this candidate
    public init(dictionaryLiteral: (Bool, Bool)...) {

It seems to me that this behaviour is inconsistent. The situation is, to my eye, no more ambiguous than it was before. It's clear to see that any of the functions in question may be selected as an implementation of a zero-argument initializer. It's even clear enough that needing to provide two default arguments instead of one should make the new initializer in Second a lower priority choice than the old one.

What is less clear is why having two-or-more optional arguments is considered the same level of fittedness to calling a variadic initialiser with zero entries. I would make the case that either both of the initializers in Second should be considered higher priority than the variadic initializer in First, or neither of them should.

There are multiple workarounds for this, but in general this has the effect of meaning that if you create a type that:

• has at least one initializer that takes two or more arguments, all of which are optional; AND

• has no initializers that take fewer than two arguments

can never safely be given a variadic initializer, and so can never safely be conformed to almost any of the ExpressibleBy family of protocols.