Question: Is there a way to conform to a Swift protocol using default values?

The following example results in a `Type 'FunExample' does not conform to protocol 'Example'`:

```
protocol Example {
    func doSomething(with: String)
}

class FunExample: Example {
    func doSomething(with: String, butMakeItFun: Bool = true) {
        // implementation
    }
}

```

...even though I actually implicitly conform since this is identical to:

```
protocol Example {
    func doSomething(with: String)
}

class FunExample: Example {
    func doSomething(with: String) {
        self.doSomething(with: with, butMakeItFun: true)
    }
    func doSomething(with: String, butMakeItFun: Bool) {
        // implementation
    }
}

```

Is there a cleaner way to provide conformance using default values? Or am I missing something conceptually when I say that the first example *should* also pass conformance?

To clarify: I understand *why* the error is produced. My question is more conceptual (whether Swift *should* work this way) and whether there is an elegant way around it.

Answer: 
You can go with `extension` for the more cleaner way! Make an `extension` with the same `protocol` methods and pass the default values which you want. Let's say:

```
protocol Example { //Main Protocol
    func doSomething(with: String, butMakeItFun: Bool)
}

extension Example { //Make to pass the default values if you want
    func doSomething(with: String, butMakeItFun: Bool = false) {
        return doSomething(with: with, butMakeItFun: butMakeItFun)
    }
}

class FunExample: Example { //Protocol Acceptance
    func doSomething(with: String, butMakeItFun: Bool) {
        debugPrint("\(with)")
        debugPrint(butMakeItFun)
    }
}

```

You can call it via following ways:

1. `FunExample().doSomething(with: "Hello Default Values...")`
2. `FunExample().doSomething(with: "..........", butMakeItFun: true)`

> 
> Update
> 
> 
> 

So based on your comment, here is what I have came up! You can take a variable under the `protocol` which surely says `true` or `false` as a default implementation and later-on you can change it in your `class`.

```
protocol Example {
    var isFun: Bool {set get}
    func doSomething(with: String)
}

class FunExample: Example {

    //var isFun: Bool = false - In case you want to change value

    func doSomething(with: String) {
        doSomething(with: with, butMakeItFun: isFun)
    }

    func doSomething(with: String, butMakeItFun: Bool) {
        debugPrint(with)
        debugPrint(butMakeItFun)
    }
}

extension Example {
    var isFun: Bool {
        get { return true /* Your Default Value */ } set {}
    }
}

```
After some research & thinking, it turns out that it is conceptually correct for Swift *not* to support this.

The idea of protocol conformance is to *ensure* that your class fits certain requirements and can provide that functionality without issue. This cannot be achieved if there would be implicit conformance.

Why? Consider the original example, slightly modified:

```
protocol Example {
    func doSomething(with: String)
}

class FunExample: Example {
    func doSomething(with: String, butMakeItFun: Bool = true) {
        // implementation
    }
    func doSomething(with: String, andDoSomeOtherStuffWith parameter: String = "") {
        // another implementation
    }
}

```

*If* Swift were to assume that `func doSomething(with: String, butMakeItFun: Bool = true)` conforms to `func doSomething(with: String)` because of the default values, then this would introduce ambiguity (since the other doSomething function also conforms).

To put it another way, here `FunExample` does not actually implement the feature `doSomething(with: "Asdf")` implicitly because simply calling this function on the class would result in an `Ambiguous use of 'doSomething'` error.

As such, it is conceptually not possible to rely on default values to implicitly assume protocol conformance.