MODERATOR NOTE: I moved these posts from the acceptance thread for
if let. Apologies, I would have written an opening post myself but I don't know how to do that with the discourse split discussion feature so I'm editing the starting post, which was feedback on this acceptance. – Ben
I don't like to be negative, but I feel I have to express my discontent about this decision.
Hi @Paulo_Faria - the goal of announcement threads is for clarifications about the decision or related follow up suggestions, such as Klay’s post above.
Please don’t use the thread to post reactions to the decision going against feedback posted during the review. It adds noise to the forums that isn’t helpful to the community, as announcement posts tend to devolve into relitigation threads.
Not my post - another 'K' 
Is there an appropriate place to express discontent? I'm sure the core team would like to receive feedback about the decisions it makes.
Dang sorry, it does appear to be a subtly different shade of cyan now I look at it!
There was ample time during the pitch and review phases to express your opinion. I should think the Core Team is not going to listen to any complaints now unless they demonstrate active harm caused by the new feature.
While I did express my views on the proposal during the review phase, I also wanted to express my discontent about the acceptance of the proposal. These are related, but different things. I do think it's valuable for the core team to hear feedback about the decisions it makes. I completely respect their work and consider Swift one of the most pleasant languages to work with. However, naturally, I don't agree with all the decisions they make. They are free to ignore the community response after they make a decision, but in my opinion that wouldn't be wise. I'm sure they expected discontent, specially with such a highly controversial topic. I don't want to derail the goal of this topic (the original topic of this post, which was moved by @Ben_Cohen) as @Ben_Cohen mentioned, but I still think my feedback is valuable and would like to do it in the most appropriate way. That's why I asked where would the most appropriate place for that be.
So this turned into a meta discussion. I don't want to waste anybody's time, as I value my own time and, naturally, others' as well. I just wanted to express my discontent about the acceptance of SE-0345, because I think that that is valuable information for the core team, which might help them with other decisions in the future. As I said to @Ben_Cohen in a private message. I don't think the core team should second guess every decision they make. Sometimes I think we just have to "shut up and take it", but not always. So I asked for an appropriate place to do that. Would be nice to have a structured way to give this kind of feedback, but I know it would be tricky. There's also the fact that, after the ship has sailed, there's not much more that can be done, depending on the proposal, its impact, etc.
@Paulo_Faria, do you have specific feedback that goes beyond both “I dislike this decision” and points that were already discussed during the review?
That is a good question. I don't think I have. I think we'll just have to wait and see, on the long run, if this was a good decision or not. Sorry for taking your time.
I don't have a strong opinion on SE-0345, but one thing I was surprised by in the acceptance rationale was no mention of the (perceived by me) polarization of the review feedback. I don't follow all reviews as closely as I did with this one but I was surprised to see so many folks giving their -1s, and it not be come up in the rationale. I know the evolution process is not a democracy, so it's not that I hoped everyone's "votes" would be counted, but I would have liked to see the core team acknowledge that this wasn't a landslide as they weighed the pros and cons. I imagine an acknowledgement about that would have quelled the feeling of "I don't like this and I haven't been heard" that started this thread.
Yes, @Keith. Something bothered me in this particular proposal review and acceptance, but I'm not quite sure what it is. So much so that it led me to express this here, but at the same time I'm failing to properly articulate it.
-- Edit
To be clear, it's not that I strongly oppose the proposal and just got unhappy that it got accepted. I actually mildly oppose it. However, something about its acceptance has put me off.
I think there’s likely a fair number of ideas that have been floated in the forums that never got to an implementation stage because the initial feedback was polarized - “Why invest in coding up an implementation when I can’t get consensus that this is even a good idea?”. My worry here is that accepting such polarizing proposals changes the calculus in undesirable ways and will lead to more polarizing proposals making it all the way to reviews. Some clear communication around the specific criteria under which core team is willing to accept a polarizing proposal and when they would choose not to could be helpful.
That said, I have no problem with core team accepting a polarizing proposal. Sometimes you need to break the logjam. As always lots of clear communication is key.
That's fair. I'll bring it up with the Core Team.
I understand the desire for a hard-and-fast rule here, but I do not think there is any clear guidance that the Core Team could ever give that would be objectively applicable. If a pitch is clearly not going to succeed, the Core Team will message that and not bring it up for a review.
I also think that high-volume discussions tend to be misinterpreted as being more polarized than they are, because the "-1"s produce far more posting traffic by volume. And not every "-1" is the same: a "-1 we shouldn't solve this problem at all" is a stronger against than "-1 on this specific proposal because I want a slightly different syntax". I don't know how to put that nuance into an acceptance post. I'll think about it more.
Doug
Pondering a bit more, I agree with @Keith. The acceptance rationale felt a bit rushed and underdeveloped. It didn't live up to the spirit of the discussion itself. I also felt that it failed to address other alternatives that were discussed and some important points that were made. I do believe that the rationale for polarizing discussion merits more depth and care.
The Core Team discussed what alternatives to include and what not to include in the acceptance, and we include alternatives when (1) there is something valuable to say about to the rationale for not choosing that alternative, (2) the alternative was not sufficiently addressed within the proposal itself, and (3) there is significant support for that alternative. The other alternatives discussed in the review thread did not meet that bar.
In theory, we could have a nod to every alternative proposal and write down a specific rationale for rejecting it, but the end result will be a laundry list of ideas that never would have come to review on their own. More communication is not better communication.
Doug
Even if I disagreed on this feature (and also think the acceptance of it was rushed), I will use this shortcut in my code going forward when it is available. It doesn't answer all my wishes but at least it reduces the boilerplate, which is not small thing.
Having said that...
Would there be an interest to have a different pitch, which will now be focusing on the "make shadowing intent explicit" aspect, rather than "remove frequent boilerplate" aspect?
hear := if | guard | <empty>
[head] override let foo <--> [head] let foo = foo
[head] override let foo = bar <--> [head] let foo = bar // foo was defined in outer scope
[head] override let foo = 123 //❌ Error: foo was not defined in outer scope
[head] override let foo = foo //❌ Error: remove "= foo" noise
[head] let foo = foo //❌ Error: override explicitly
I know it might feel like there is a clash with "if let foo", but we can consider it as a brand new unrelated feature (which will somewhat increase the length of "if let foo" to "if override let foo" but it will do it for a good reason of making shadowing intent explicit).
On a procedural point, I wasn’t very happy to see the phrase “The clear majority of responses to the proposal were in favor” in the motivation. My position was “-1 we shouldn’t solve this problem at all”, but I felt that @xwu and @wowbagger had covered my arguments well and didn’t want to spam, so I didn’t say anything.
Shadowing exists throughout the Swift language, as with many other programming languages, and there was no interest among the Core Team in pursuing explicit shadowing syntax.
Doug
That is one sentence that you could have added to the rationale. In my opinion, it would be an instance of good communication, not just "more communication".