Thanks for writing this up.

Some quick points.

Firstly, I think it is best if the `init(_ forwardeeReturnValue: 
Forwardee)`-style initializer be replaced by something with a distinctly-named 
argument, e.g. `init(forwardeeReturnValue value: Forwardee)`. 

For use with actual wrapper types the “init(_ wrappedValue: Wrapped)`-style 
init is too valuable to “claim” for this purpose (in particular b/c we may want 
to “adjust" the forwarded result); it’s IMHO better if we use a distinct `init` 
for the forwardee-return-value scenario so we know where the value is coming 
from.

Secondly, I would prefer partial-forwarding be given more consideration, b/c it 
seems somewhat common for me in practice at this time.

EG: I would do the following somewhat frequently:

struct FooIdentifier: Equatable, Comparable, Hashable

class Foo {
  let identifier: FooIdentifier
  let name: String

  forward Hashable to identifier
}

func ==(lhs: Foo, rhs: Foo) -> Bool {
  return lhs.identifier == rhs.identifier && lhs.name == rhs.name
}

…even though I agree that full-forwarding would the most-common scenario.

I have a few other similar cases involving non-standard-library types but they 
all fit the same basic pattern as above for `Hashable`.

Finally, I’m actually at a bit of a loss for too many uses for the generic 
forwarding mechanism; if it was added I’d use it to streamline some wrapper 
types, but beyond that I’m not seeing all that many places where I’d do much 
more than that with this feature if added.

Any chance at adding a few more-concrete motivating examples for the fancier 
cases?

> On Dec 29, 2015, at 10:37 AM, Matthew Johnson via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> I have completed a first draft of a proposal to introduce automatic protocol 
> forwarding.  I’m looking forward to feedback from everyone!

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to