I failed to mention that It is currently possible to create a protocol
extension with a default argument, but this is not ideal. This has made the
topic complex enough to warrant a new thread and I will not hijack this thread
any longer. If anyone is interested, I will start a new thread for this
proposal.
// Currently works
protocol P {
func ff( a:Int )
}
extension P
{
func ff( a:Int=1 ) {
print( "extension method" ) // I believe that this should be in
the protocol
fatalError( "There is not sensible default implementation. This method
exists to make the compiler happy" )
}
}
struct S : P {
func ff( a:Int) { // Does not override the extension method. Will not be
called unless `a` is passed.
}
}
let p:P = S()
p.ff() // Will crash. Calls the extension method, which is never "overridden"
> On Mar 26, 2017, at 3:09 PM, Christopher Kornher via swift-evolution
> <[email protected]> wrote:
>
> 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] <mailto:[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] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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
