Presumably, this is referring to the concern I raised about ambiguity and formatting. I want to clarify what that comment is claiming:
Claim 1: The examples given in the proposal's text itself make a case for not accepting the proposal because they make understanding the call-site for assertArgs more difficult. Could this potentially be fixed by formatting in a particular way, say by breaking a small line (less than 80 columns) into multiple lines? Sure. Is that what we want to actually do in practice? I don't think that's going to happen. (Maybe it is; I'd be happy to be proven wrong.)
Claim 2: For a non-semantic code formatter, it can either (a) format multiple variadic parameters properly with extra indentation for trailing arguments XOR (b) it can properly format an unlabeled argument following a labeled argument. (Tony's comment below confirms that swift-format operates on syntax without requiring name resolution). So either we accept that (a) existing code with long invocations relying on unlabeled arguments following labeled arguments gets misformatted XOR (b) new code with long invocations relying on multiple variadic parameters gets misformatted. Neither of these are appealing.
I'm a bit surprised that I did not receive any response from the review manager or the proposal authors. I have two questions here:
- Are my concerns unreasonable/unfalsifiable? Are the review manager + proposal author(s) expected to respond to all concerns raised during review?
- Let's say we adopt the formatting rule to add indentation (option (a)), which makes the multiple variadic parameters case work. Now, call-sites using APIs with unlabeled parameters following labeled parameters might get mis-formatted... Whose responsibility is it to check how widespread this regression might be in practice? Is it the responsibility of the person who raised the concern? The review manager's? The proposal authors'?