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
> <[email protected]> wrote:
>
>
> On Mar 26, 2017, at 11:12, Karl Wagner via swift-evolution
> <[email protected] <mailto:[email protected]>> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
