[Proposal Draft] automatic protocol forwarding


(Thorsten Seitz) #1

Thanks for proposing this, Matthew!

···

Am 30. Dezember 2015 um 03:05 schrieb Matthew Johnson via swift-evolution swift-evolution@swift.org:

  • Why the method-based conversion syntax for return values, rather than something a little more like a property declaration?

var number: Int
forward IntegerType to number {
static return(newValue: Int) {
return NumberWrapper(newValue)
}
return(newValue: Int) {
return NumberWrapper(newValue)
}
}

This is actually a really good idea to consider! I didn’t consider something like this mostly because I didn’t think of it. I’m going to seriously consider adopting an approach along these lines.

Great.

One possible advantage of the approach I used is that the initializer may already exist for other reasons and you would not need to do any extra work.

True. But it may also exist and not do what you want in the forwarding case. It’s easier to explicitly use the right initializer than it is to work around the forwarding system implicitly using the wrong one.

Right, I am generally leaning pretty strongly towards changing the proposal to use a solution similar to what you suggest.

That’s great. I was about to suggest something similar (like having to name the conversion functions used in the forward clause) when I read Brent’s proposal which is much more elegant, so I’d like to support that. Making this explicit without some “implicit magic” is truely important.

The one thing I’m missing is some real-life examples which would be really helpful to consider this proposal properly (Dave Abrahams already pointed this out).

-Thorsten


(Matthew Johnson) #2

Thanks for proposing this, Matthew!

* Why the method-based conversion syntax for return values, rather than something a little more like a property declaration?

var number: Int
forward IntegerType to number {
  static return(newValue: Int) {
   return NumberWrapper(newValue)
  }
  return(newValue: Int) {
   return NumberWrapper(newValue)
  }
}

This is actually a really good idea to consider! I didn’t consider something like this mostly because I didn’t think of it. I’m going to seriously consider adopting an approach along these lines.

Great.

One possible advantage of the approach I used is that the initializer may already exist for other reasons and you would not need to do any extra work.

True. But it may also exist and *not* do what you want in the forwarding case. It's easier to explicitly use the right initializer than it is to work around the forwarding system implicitly using the wrong one.

Right, I am generally leaning pretty strongly towards changing the proposal to use a solution similar to what you suggest.

That's great. I was about to suggest something similar (like having to name the conversion functions used in the forward clause) when I read Brent's proposal which is much more elegant, so I'd like to support that. Making this explicit without some "implicit magic" is truely important.

Yes, I am definitely going in this direction. I want to think it over a bit more and will update the proposal soon.

The one thing I'm missing is some real-life examples which would be really helpful to consider this proposal properly (Dave Abrahams already pointed this out).

I'm working on this right now. I was really looking forward to feedback on the solution so I decided to share a draft before the motivation was fully written. Maybe that was a mistake, or at least should have been called out more clearly.

···

Sent from my iPad

On Dec 30, 2015, at 12:52 AM, Thorsten Seitz <tseitz42@icloud.com> wrote:
Am 30. Dezember 2015 um 03:05 schrieb Matthew Johnson via swift-evolution <swift-evolution@swift.org>:

-Thorsten