> On Dec 30, 2015, at 10:06 AM, plx via swift-evolution
> <[email protected]> wrote:
>
> 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
> }
I should have also mentioned a couple of other things here. First, you’re not
getting much because this only forwards the hashValue property. But you could
argue it is more clear and it does prevent you from making a silly mistake even
though the forwarding implementation is really simple.
Second, even without partial forwarding it is possible to do this under the
current proposal. You just need to declare a new protocol that only contains
the member you wish to forward:
protocol HashValuable {
public var hashValue: Int { get }
}
class Foo: Hashable {
let identifier: FooIdentifier
let name: String
forward HashValuable to identifier
}
func ==(lhs: Foo, rhs: Foo) -> Bool {
return lhs.identifier == rhs.identifier && lhs.name == rhs.name
}
I
>
> …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
>> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
