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

[Xiaodi Wu]

I'm in favor of both of these.

However, the issue outlined in (1) with respect to labels is problematic.
The core team's post-Swift 3 plan (
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html)
for evolving from SE-0111 solves that problem without the need to invent
new rules for (1). IMO, that issue should be addressed first, then (1).
On Sun, Mar 26, 2017 at 14:04 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> 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/47feec69/attachment.html>