Pitch: Property Delegates

[Douglas_Gregor]

@djbe

I think @davedelong's comment is spot on, and whatever proposal that would implement this, should also consider the bigger picture

If this proposal goes through and some proxy mechanism later, they should be similar in how they work and work well together. Swift shouldn't become a language with a bunch of different things stapled on, it should be consistent and well thought-out.

For this proposal, it might be worth it taking a step back, and consider what we want to achieve long term.

I disagree, and I'm going to disagree more strongly than is strictly necessary because I think this general pattern of discourse can be harmful to the process, particularly for less-experienced proposers.

The pattern looks like this:

1. This proposal looks like a form of
2. Something like could be useful elsewhere in Swift
3. You should go design all of because your proposal might end up different after that exercise

Abstractly, it's a reasonable line of argument: we want to find the generalization that ties together different ideas, rather than having disparate features that don't compose.

However, when making this "step back and consider the larger picture" argument, it is important to show that there is a plausible larger picture, and what it might look like. That's completely missing here: the entire argument rests on the idea that there is some "proxy pattern" that would subsume property delegates and a bunch of other use cases.

• Those use cases aren't spelled out.
• A more-general feature that covers those use cases isn't spelled out.
• The way in which that more-general feature serves the use cases of the proposal under discussion isn't spelled out.

In fact, there is literally nothing in the post that ties together the feature proposed (property delegates) and the proposed larger picture (proxies) beyond the use of the term "proxy pattern." The suggestion is meant in good faith, but its effect is very different: it's signing the proposal author up for some unspecified amount of work with unclear goals. For a less-assured proposal author, it acts as a roadblock: it's hard to say "no" to a goal that is abstractly good, but impossible to address the comment in a constructive way without exaggerating the scope of the proposal beyond what the author intended (or even cares about).

Contrast this with the suggestion to tie this in with custom attributes. There, there is a clear link ("re-use the syntax from this other pitch instead of inventing new syntax"), a clear "larger picture" (a pitch for the generalization we're talking about), and clear goals ("we only need the attribute syntax and nothing else new"). We've been having a useful discussion about the technical trade-offs ever since, because the suggestion was concrete enough that we can discuss specific details.

Doug