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

[肇鑫]

Vatsal thinks the default works as a default value keyword, which restricts
that the implementation of the function must have a default value. The
default value is not set in the protocol. It is a restrict keyword.

Vatsal thinks that will be a good idea, as that will make Protocol like,

protocol A {
    func foo()
    func foo(bar: String)
}

simplified as

protocol A {
    func foo(bar: String = default)
}

So if you implement protocol A

struct X:A {
    func foo(bar: String) { // will show an error as protocol A restricts a
default value
        ..
    }
}

However, there is also a pitfall here. If foo() is not a foo(bar:String)
with a default value, but some operations without using the bar parameter?
Then the logic is not the same. You can't define another func foo() as the
compiler can not distinguish from foo() to foo(bar:String = "John") with
default value.

zhaoxin

On Sat, Jan 16, 2016 at 7:35 PM, Goffredo Marocchi <panajev at gmail.com>
wrote:

> I still think that, except in certain very generic cases, default methods
> are something I would be wary of being easily abused.
>
> Protocols, Java style interfaces, they allow users to focus only on a
> generic behaviour/contract without having to rely or being able to rely
> and/or make bonding assumptions on any implementation details of the type
> conforming to the protocol. Default methods in a protocol still seem to go
> in the opposite direction although they do offer a lot of convenience and
> open up new styles.
>
> Sent from my iPhone
>
> On 16 Jan 2016, at 11:04, Haravikk via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I think that the point of allowing defaults in protocols is so that you
> can assume a default for all types conforming to that protocol. To use your
> example, if you receive an instance of Name, you can only call
> printSomething() without arguments if you test that it is an instance of
> type Name. If instead you test its conformance to the Good protocol (which
> you might do if there are a lot of different types conforming to Good) then
> you have to provide a value, because you can’t infer that every possible
> implementation will have a default.
>
> Regarding this proposal however I think it might be useful to have a
> distinction between a protocol function that specifies a default value for
> all implementations (that they must all conform to) versus one that
> specifies that implementations must have a default value, but not what that
> value must be.
>
> For example, to have a fixed and altered default we currently we have to
> do things like this:
>
> protocol Protocol {
> func functionWithSpecificDefault(argument:String)
> func functionWithAnyDefault(argument:String)
> }
>
> extension Protocol {
> func functionWithSpecificDefault() {
> self.functionWithSpecificDefault(“Foo”) }
> func functionWithAnyDefault() { self.functionWithAnyDefault(“Foo”) }
> }
>
> class MyClass : Protocol {
> func functionWithSpecificDefault(argument:String) { /* Implementation here
> */ }
> func functionWithAnyDefault(argument:String) { /* Implementation here */ }
>
> func functionWithAnyDefault() { self.functionWithAnyDefault(“Bar”) } //
> Override default
> }
>
> Which could be replaced by:
>
> protocol Protocol {
> func functionWithSpecificDefault(argument:String = “Foo")
> func functionWithAnyDefault(argument:String = default)
> }
>
> class MyClass : Protocol {
> func functionWithSpecificDefault(argument:String = “Foo") { /*
> Implementation here */ }
> func functionWithAnyDefault(argument:String = “Bar") { /* Implementation
> here */ }
> }
>
> However, this has the added advantage that implementing
> functionWithSpecificDefault with a default other than “Foo” would cause a
> compiler error, while doing so for functionWithAnyDefault would not (but
> specifying no default at all would, as one is required).
>
> On 16 Jan 2016, at 10:15, 肇鑫 via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> No. Although you protocol's function doesn't has a default parameter
> value. Your implementation does. So you don't need to define another func
> function() in your protocol.
>
> protocol Good {
>     func printSomething(something:String)
> }
>
> struct Name:Good {
>     func printSomething(something: String = "John") {
>         print(something)
>     }
> }
>
> Name().printSomething()
>
> above code works.
>
> zhaoxin
>
> On Sat, Jan 16, 2016 at 6:05 PM, Vatsal Manot <vatsal.manot at yahoo.com>
> wrote:
>
>> It serves as a better (if not simpler) substitute for the following
>> pattern:
>>
>> protocol Protocol
>> {
>>     typealias Argument
>>
>>     func function()
>>     func function(_: Argument)
>> }
>>
>>
>> On 16-Jan-2016, at 3:29 PM, 肇鑫 <owenzx at gmail.com> wrote:
>>
>> I wonder where is the good for a protocol designer on this?
>>
>> zhaoxin
>>
>> On Sat, Jan 16, 2016 at 5:23 PM, Vatsal Manot via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> Currently, the following the code fails with multiple errors:
>>>
>>> protocol Protocol
>>> {
>>>     typealias Argument
>>>
>>>     func function(argument: Argument = default)
>>> }
>>>
>>> I propose that we allow protocols to require functions with default
>>> parameter values. I can’t see any disadvantages to this, and the change
>>> would only be additive.
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>>
>>
>> --
>>
>> Owen Zhao
>>
>>
>>
>
>
> --
>
> Owen Zhao
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160116/1ca79791/attachment.html>