# \[Accepted\] SE-0284: Allow Multiple Variadic Parameters in Functions, Subscripts, and Initializers

**URL:** <https://forums.swift.org/t/accepted-se-0284-allow-multiple-variadic-parameters-in-functions-subscripts-and-initializers/38567>\
**Category:** Announcements\
**Created:** [July 19, 2020, 7:25pm UTC](https://forums.swift.org/t/accepted-se-0284-allow-multiple-variadic-parameters-in-functions-subscripts-and-initializers/38567 "2020-07-19T19:25:34Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [July 20, 2020, 8:09pm UTC](https://forums.swift.org/t/accepted-se-0284-allow-multiple-variadic-parameters-in-functions-subscripts-and-initializers/38567/3 "2020-07-20T20:09:57Z")

</div>

@typesanitizer Reading back over your comment now, I can't identify any part of the critique that isn't more generally applicable to having variadic parameters in non-primary positions. E.g., with regards to `assertArgs` you say:

> [@SE-0284: Allow Multiple Variadic Parameters in Functions, Subscripts, and Initializers](https://forums.swift.org/t/se-0284-allow-multiple-variadic-parameters-in-functions-subscripts-and-initializers/38225/8):
>
> IMO the Before case is a clear win in terms of understanding when I'm looking at the call-site. The After case makes it look like `"-bar"` is a separate unlabeled argument. The `[]` delimiters in the Before case make it clear that `"-bar"` is part of the argument labeled `leaving:` .

But an alternate version of the API could be written (without SE-0284) as:

```swift
try assertArgs(["swift", "-foo", "-bar"], parseTo: .interactive, leaving: "-foo", "-bar")

```

The same goes for the `addSubviews` example. Perhaps the "after" versions are not the best examples of APIs that could be helped with this proposal, but AFAICT your comment would be more applicable as an argument against adopting those _specific_ APIs (and could perhaps apply to a more general pattern of APIs which might use SE-0284).

> [@typesanitizer](#):
>
> Are the review manager + proposal author(s) expected to respond to all concerns raised during review?

IMO, this is unfeasible as a general policy. We certainly can't _force_ proposal authors to respond to every concern, nor does it seem reasonable to me to reject an otherwise-sound proposal on the grounds that an author did not respond to some comment. It's the job of the Core Team to synthesize all the feedback a review generates and make a decision, and they are capable of doing that whether or not every comment has a response.

Of course, if someone raises a concern in a review thread, by not responding the proposal author is foregoing their last opportunity to convince the Core Team that the concern need not be (or already is) addressed by the proposal—but ultimately, that's their prerogative.

ETA: We do currently have this note as part of the [Swift Evolution Process](https://github.com/apple/swift-evolution/blob/master/process.md) document:

> To avoid delays, it is important that the proposal authors be available to answer questions, address feedback, and clarify their intent during the review period.

This sort of 'soft' expectation is about as strict as I'd like things to be, officially.

---

_[View the full topic](https://forums.swift.org/t/accepted-se-0284-allow-multiple-variadic-parameters-in-functions-subscripts-and-initializers/38567)._