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 (mailto:[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] (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
