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 <[email protected]> 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 <[email protected]>> 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 < > [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
