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 < [email protected]> wrote:
> > On Mar 26, 2017, at 11:12, Karl Wagner via swift-evolution < > [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
