Sure. I don't see how that is a problem with the critique. I'm pointing out what in my view is a code anti-pattern, and the fact that the proposal uses the same kinds of examples in a positive light means that I'm less inclined to support the proposal.
One of the reasons to have examples (and the discussion!) is to convince the reviewers that the feature can be used to create good APIs. Most features come with some downsides too, and that's understood. What I'm saying is that the examples given in the proposal are not doing a good job of convincing one how this feature enables people to write APIs that do not impose an additional understanding burden at the call-site. A feature cannot (and IMO should not) be evaluated based on examples that are not part of the proposal or discussion. If someone has a positive example, they should bring it up, so as to strengthen the proposal. If someone has a negative example, they should still bring it up, to highlight the proposal's weaknesses.
You'll notice that I didn't give a -1 to the proposal. That's very deliberate, because I hadn't made up my mind. I was, and am open to being convinced by better examples.
Ok that's fair, at least now I understand where you stand on the point raised. I disagree on the "significant" bit, but that's subjective, so I don't want to dwell on that.
IMO this is a non-starter for many projects; in other language communities (esp. Go, Elm and to some extent Rust), I've definitely seen places with "everything goes through the formatter, no questions asked, no tweaking by hand". That said, I don't know what % of folks in the Swift community feel this way, so I'm happy to give you the benefit of doubt here, y'all almost certainly write a lot more Swift code than I do.
That's fair. Based on the given examples, I disagree with you and the core team on the cost/benefit here, but it is what it is. We don't need to agree on everything.