I think we need another round of revision on this feature before it’s ready for prime time.
• • •
First, the compiler-synthesis aspect is essentially sugar to reduce boilerplate. We can already write computed properties that trivially forward access to another property as the proposal describes. Sure, doing so manually takes a few extra lines of code, but it is certainly a pattern that people can employ today.
So…are they?
Is this pattern in common use? Do major projects define their own UserDefaults
type in this manner? Or DelayedImmutable
or CopyOnWrite
or Atomic
or any of the other examples shown in the proposals?
If the pattern of encapsulating behavior in a delegate type is in such high demand to warrant special syntax and inclusion in the standard library, then I would expect to see it in regular use already even without the sugar.
• • •
Second, although the proposal calls itself “property delegates”, it does not actually enable programmers to delegate one property to another. Instead, it is shaped much more like “property behaviors lite”.
The dollar-sign spelling for the delegate seems entirely magical, and goes against the existing precedent of using an underscore. I would prefer to see the synthesized property either spelled with an underscore and always private
, or else invisible, unnamed, and inaccessible.
In the case where a different name or visibility is required, I would expect it to be possible for a programmer to manually declare the delegate property, with some way to indicate that the main declaration delegates to it. After all, if we are going to introduce property delegates, the core feature should be providing a convenient way to delegate one property to another.
• • •
If instead what we actually want is property behaviors, then we should start with a clear roadmap so we know where we want to end up. It seems clear that access to self
is important, and it is not part of the current proposal.
The “future directions” section talks at length about making self
available, which indicates that the authors recognize its importance. Yet the proposal still does not offer that functionality.
I do not think we should pursue this in fits and starts. Instead, we should prepare a single cohesive vision for it. Perhaps multiple proposals will still be required, but regardless of that we should know where we are planning to go.
• • •
Furthermore, with a significant change like adding custom @
attributes, I strongly believe we should have more time with the toolchain so that people can try out the feature, gain real-world experience with it, and work through the kinks.
I would not want to review this feature until I had the opportunity to use it hands-on for an extended amount of time. After all, there could be many different designs in this space, and we should be highly confident we have found the right one before permanently adding it to the language.