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

[Karl Wagner]

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: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 (mailto:swift-evolution at swift.org)>  wrote:
>   
> >   
> >   
> >
> >   
> > On Mar 26, 2017, at 11:12, Karl Wagner via swift-evolution  <swift-evolution at swift.org (mailto: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 (mailto: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/5f4fd598/attachment.html>