> I don’t want this thread to get distracted with memberwise initialization
Makes sense in general, but Kotlin solves those problems as a whole, and the
major benefit of their approach is that everything fits together really fine.
But I'll skip everything that is not related to forwarding.
> One approach I considered would look like this:
>
> class Forwarder: P {
> // I didn’t like `implements` but didn’t have a better idea before I
> abandoned this approach
> var forwardee: Forwardee implements P
> }
Honestly, I'm can't see the value this discarded variant has for this
discussion… you have to pit your proposal against Kotlin if you really want to
convince anyone of its superiority.
> With the memberwise initialization proposal you also have the initializer
> synthesized automatically. The only thing it doesn’t do that your Kotlin
> example does is automatically declare conformance. This was an intentional
> design decision because it allows for additional expressivity. This is
> addressed in the alternatives considered section of the proposal.
Can you be more precise? Kotlin clearly states what a class is doing in its
first line, with all expressivity that is necessary by practical means.
> Another difference that is maybe subtle but I think important is that with
> the approach I considered forwarding is declared in the body of a type or
> extension which emphasizes the fact that forwarding is an implementation
> detail, not something users of the type should be concerned with.
But what is the benefit of this emphasis? No solution requires to make the
details visible in the public interface, and the ability to bury an important
thing like protocol conformance somewhere in the class implementation is no
advantage for me.
> This approach was abandoned as it leads to problems in expressivity and
> clarity. Please see alternatives considered for an elaboration of that.
> This is especially true with the new approach to handling Self values that
> Brent suggested. That approach requires additional syntax around the
> forwarding declaration, but adds both clarity and expressiveness.
I think there is little need to worry about expressiveness for a feature that
most potential users will probably never utilize in real code — and I don't
think options like not conforming to a protocol that is forwarded is a big win
here. It looks to me like you are optimizing for very uncommon cases, and
sacrificing ease of use in the situations that are the most common by far.
> It appears to me that you value conciseness very highly. I do value
> conciseness but I also value safety, clarity, and expressiveness.
No, I value elegance and simplicity — they often lead to clarity and safety.
>> Why not simply make this feature syntactic sugar and just auto-generate the
>> forwarding methods?
>
> That is exactly what this proposal does. Why do you feel it is not doing
> that?
you're right, guess I mixed up the proposal with something else; so at least we
agree on how it should work ;-)
I'm not saying Swift has to copy another language, but I doubt that anyone who
knows Kotlin would actually consider to drop their solution in favor of what is
currently discussed...
Tino
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
