I wasn't a member of the core team at the time, and I'm speaking in my personal capacity, and I am generally wary of review decision relitigation but... I think this is a case of a decision that is worth revisiting, even in the absence of something changing, on the basis that the rejection justification reason is fairly weak.
Funnily enough, that weakness shows up also in the motivation given in the OP of this thread. Minimizing diffs does indeed not seem enough of a justification. I've also seen arguments that this helps with code generation, and that also seems insufficient.
The reason I wish Swift had this feature – a reason I bump into often, maybe even daily – is that I often find myself commenting out the last line in a tuple or argument list (at call or def site). When working with code, I find myself doing this very frequently, and whenever I hit this problem I am frustrated by the inconsistency with collection literals. Instead of just sticking a // (via a keyboard shortcut) at the start of the last entry, I must either edit the line, or weave around the new line with /* */, or adopt some formatting hack like putting the commas after the new lines.
Here is an example I hit today. I was experimenting with the performance difference using a 3-tuple vs a 4-tuple to represent a 3-dimensional vector:
var velocity = Vector(
1.66007664274403694e-03 * DAYS_PER_YEAR,
7.69901118419740425e-03 * DAYS_PER_YEAR,
-6.90460016972063023e-05 * DAYS_PER_YEAR,
// 0
)
By contrast, if I had been using SIMD types, which are initialized with array literal syntax, this would not have been a problem. And of course, I comment in and out collection elements all the time too.
It is possible I'm just a weird case, and the kind of code fiddling I tend to do means this happens to me more than other programmers, and so it's not enough reason to add this feature. But I don't think so.
Perhaps the introduction of variadic generics and APIs such as SwiftUI has altered the nature of Swift being written these days. Or perhaps what has changed is that just more real-world swift code is being written than in 2016 less than 2 years after Swift was introduced, and so what I experience myself fairly frequently might strike a chord with the now very large number of developers who work with Swift daily.
Finally, the reason:
Finally, the core team does not want to encourage or endorse a coding style that puts the terminating right parenthesis on a line following the arguments to that call.
is very mysterious to me, since doing this was already the adopted style of the Swift standard library codebase, when lines exceed 80 chars. It has since also been adopted as the standard style in both Xcode and swift-format. While none of these (except maybe the style used in the std lib, at least for swift committers) is "official", I do think they're a indication that an (unexplained) opposition to them was not a good justification for this part of the argument.
