> On Dec 30, 2015, at 10:06 AM, plx via swift-evolution
> <[email protected]> wrote:
>
> Thanks for writing this up.
Thanks for responding with comments.
>
> 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.
Did you look at the approach Brent suggested yesterday? I’m going to update
the proposal using something similar to that. We won’t be claiming any init at
all. It will be slightly less concise in the common case but will add clarity,
expressiveness, and resolve problems related to forwarding to more than one
member of the same type.
>
> Secondly, I would prefer partial-forwarding be given more consideration, b/c
> it seems somewhat common for me in practice at this time.
If somebody from the core team was enthusiastic about including partial
forwarding in the initial proposal rather than as an enhancement that would
certainly motivate me to reconsider.
As I stated earlier and in the proposal, one reason I left it out is that
partial forwarding introduces similar concerns that arise with subclassing.
Should a protocol or a type designed to be a forwardee be able to include
annotations indicating that some members cannot be “overriden” by a forwarder?
I haven’t had time to fully consider whether that is a good idea or not and if
it is, what it would look like, how it should work, etc. I am reluctant to
introduce partial forwarding without really thinking this through.
>
> 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
> }
>
Thanks for providing an example! It looks like you would have two different
instances representing the same entity, possibly one serving as an edit buffer.
Is that why they might have the same identifier but different names?
> …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?
Yes, this is needed and I am working on it now.
>
>> 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
