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

[Xiaodi Wu]

The core team did call it a future "purely additive proposal"--implying
that there does need to be one written. I do believe that someone did make
a start at implementing compound names, which was not merged as-is because
there has been no proposal. Should be an easy and uncontroversial one to
write though.


On Tue, Mar 28, 2017 at 16:27 Karl Wagner <razielim at gmail.com> wrote:

> Thanks for that link, it definitely solves the label issue, and even some
> label issues I didn't consider; for example, you couldn't implement
> BidirectionalCollection using closures without it:
>
> let index: (Index)->Index // should be index(before:)
> let index: (Index)->Index // should be index(after:)
>
> I'm wondering: if somebody were to implement that amendment , would it
> require an evolution proposal? Presumably not, since the amendment is part
> of the condition under which SE-0111 was accepted, right?
>
> - Karl
>
> On Mar 26, 2017 at 10:11 pm, <Xiaodi Wu <xiaodi.wu at gmail.com>> wrote:
>
> 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/20170328/1293e336/attachment.html>