[swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

[Christopher Kornher]

A comment: Your description of #2 is a little confusing. Functions with default arguments can currently satisfy protocols. Perhaps it should be “Allow functions with extra default arguments to satisfy protocols"

I have not had the need for the features you mentioned, but it would be nice to allow them both. Having closures satisfy protocol requirements would improve support for composition.

I would like to add one: Allow protocols to define default arguments. Implementations can define default arguments in protocol implementations but that is not particularly useful for protocol oriented programming. Perhaps I should start a different thread, but these are related. Can we call it

3) Allow protocols to define default parameters

protocol P {
    func f( a:Int )
    func ff( a:Int=1 )      // Error: "Default argument not permitted..."
}

struct S : P {
    func f( a:Int=2 ) {     // Currently legal, but not useful for protocol oriented programming
    }
    
    func ff( a:Int=3 ) {   // A little confusing to the uninitiated perhaps, but useful
    }                      // and consistent with method overrides.
}

let p:P = S()

p.f()                       // Fails (as it should since the protocol does not have a default value)

p.ff()                      // Would succeed if the protocol could have a default param.
                            // I find myself wanting this behavior frequently

> On Mar 26, 2017, at 1:04 PM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> On Mar 26, 2017, at 11:12, Karl Wagner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> I’d like to pitch the following two language changes. Both of them are technically possible today if you manually write thunks for the relevant protocol requirements, but it would be nice if we allowed them to be written directly:
>> 
>> 1) Allow closures to satisfy function requirements in protocols
>> 
>> protocol MyProtocol {
>>     func run(param: Int) -> String
>> }
>> 
>> struct MyStruct : MyProtocol {
>>     var run : (Int)->String   // Satisfies requirement MyProtocol.run
>> }
>> 
>> Among other things, it would make writing type-erased wrappers in the style of AnyCollection much easier. The only obvious niggle is that the argument label wouldn’t be required when invoking the closure directly. The labels have no type-system significance, but it does make it subtly easier to write less generic code than you intend do. We could solve this by having code-completion favour protocol methods in this situation, or simply to require the label when invoking a closure which implements a known protocol requirement.
>> 
>> 2) Allow functions with default parameters to satisfy function requirements in protocols
>> 
>> protocol Sportsplayer {
>>     func goalsScored() -> Int
>> }
>> 
>> struct SoccerPlayer: Sportsplayer {
>>     struct GoalType : RawOptionSet {
>>         static let Shot   = GoalType(0x1)
>>         static let Volley = GoalType(0x10)
>>         static let Header = GoalType(0x100)
>>         static let Any    = GoalType(0x111)
>>     }
>> 
>>     // Default value .Any means this conforms to Sportsplayer
>>     func goalsScored(type: GoalType = .Any) {
>>       //...
>>     }
>> }
>> 
>> struct Footballer: Sportsplayer {
>>     struct GoalType : RawOptionSet {
>>         static let Touchdown = GoalType(0x1)
>>         static let FieldGoal = GoalType(0x10)
>>         static let Any       = GoalType(0x11)
>>     }
>> 
>>     // Default value .Any means this conforms to Sportsplayer
>>     func goalsScored(type: GoalType = .Any) {
>>       //...
>>     }
>> }
>> 
>> I often find that I want to add some optional, implementation-specific parameter to a function which implements a protocol requirement. That’s currently not possible, and it’s a bit annoying.
> 
> IIRC, the issue with #2 is that protocols specify declaration-site details, but default parameters are implemented at the call-site. At least I believe that statement was accurate about a year(ish) ago... Dunno if anything has changed since then.
> 
> If it can be made to work, though, I'd be in favor of it, and I think #1 as well.
> 
> - Dave Sweeris
> _______________________________________________
> 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/20170326/1b355030/attachment.html>