[swift-evolution] [Proposal] Allow protocols to require functions with default parameter values.

[davesweeris at mac.com]

> On Jan 16, 2016, at 17:28, 肇鑫 <owenzx at gmail.com> wrote:
> 
> Hi Dave,
> 
> Like you said, you approach does not solve the bug.
> 
> And this is the bug: If your protocol `Foo` has a function `foo(X)`, and your type has a function `foo(Y)` where Y can be turned into X through the use of default parameters, then it’s impossible for your type to conform to `Foo`, even though you could use it as a `Foo` in your code. In practice, I think this only matters if you’re using “macros” like __LINE__ or something as your default parameter, but it’s still annoying (to me, anyway).
> 
> 
> ​as this proposal does​.

No, I was saying that (at least at a glance) I didn’t think the original proposal solved the problem I described, and that I thought my “counter” proposal would have all the functionality (albeit from the “other direction”) that Vatsal was proposing *and* fix the glitch.

…Maybe we’re saying the same thing.



> I still think if we can call instance.function(), we should also call (instance as protocol).function(). If we can't, there must be something not right here.
> 
> zhaoxin


You can, as long as your protocol isn’t restricted to only being used as a generic constraint (no Self or typealiases):
protocol Foo {
    func foo() -> String
}

extension Int : Foo {
    func foo() -> String { return "lovely" }
}

func bar(x: Any) -> String {
    if x is Foo { return "Here, have some \((x as! Foo).foo()) foo." }
    else        { return "NO FOO FOR YOU!!!" }
}

print(bar(0))   //Here, have some lovely foo.
print(bar(""))  //NO FOO FOR YOU!!!

- Dave Sweeris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160116/17f92deb/attachment.html>