<div dir="ltr">I'm also having trouble getting behind this proposal.<div><br></div><div>IMO, variadics as implemented today in Swift (and in Java) are a subset of the problems that can be solved with variadic generics. They're more limited because you can't today support heterogeneous argument lists without losing static type information by forcing all values to be a less-specific type (like Any, in the worst case).</div><div><br></div><div>Given that Swift will (hopefully) support variadic generics in the future, I'd love to see the current variadic syntax/implementation go away entirely and be reïmplemented using variadic generics instead. The solution proposed here is too specific given that possible future and I think it's more of a lateral move with few benefits rather than an incremental move that gets the language toward a greater goal.</div><div><br></div><div>Considering the set of problems where one would like to support both an inline variadic homogeneous argument list syntax *or* splatting in a collection, I think that set is small enough that a special syntax isn't necessary. I would consider an API that *only* supports homogeneous variadic arguments a poorly designed API, and we shouldn't add complexity to the language to support that; we should encourage API authors to write versions that take collections instead, and if they really want to support variadics, implement it in terms of the collection-taking method.</div><div><br></div><div>I'm also of the opinion that for most use cases involving homogeneous argument lists, having to add the two characters "[" and "]" around the arguments is not a significant burden to end users.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 20, 2016 at 1:25 PM Leonardo Pessoa via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm strongly opposed to this too. I'm not only not fond of the<br>
proposed syntax but I also don't really see how allowing other types<br>
in variadics will help anything. Also, there may be necessary more<br>
complex code to support all the extra (or even previously unknown)<br>
types that could be used with this syntax, making the language much<br>
more complex.<br>
<br>
L<br>
<br>
<br>
On 20 July 2016 at 16:54, Chris Lattner via swift-evolution<br>
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> On Jul 20, 2016, at 11:37 AM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>><br>
>>> On 20 Jul 2016, at 14:55, Tino Heth <<a href="mailto:2th@gmx.de" target="_blank">2th@gmx.de</a>> wrote:<br>
>>><br>
>>><br>
>>>> Am 17.07.2016 um 18:31 schrieb Haravikk <<a href="mailto:swift-evolution@haravikk.me" target="_blank">swift-evolution@haravikk.me</a>>:<br>
>>>><br>
>>>> I may move discussion of other collection types to its own section though, to make the core proposal as simple as possible, and leave it up to the core team whether to do that part.<br>
>>> imho this is a good idea: Its increased power is a major argument for the proposal, but the schedule seems to be very tight already… and I guess the discussion about possible problems caused by variadic functions which can be called with an explicit collection could be a real distraction, whereas the basic idea is so clear that there shouldn't be any valid reasons to not accept it.<br>
>><br>
>> I've created a new pull request for this, you can view the updated file here:<br>
>> <a href="https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/nnnn-variadics-as-attribute.md" rel="noreferrer" target="_blank">https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/nnnn-variadics-as-attribute.md</a><br>
>><br>
>> Hopefully it's still clear; I know I have a nasty tendency to be overly verbose with wording and stuff, though the first example should keep the meat of the proposal straightforward =)<br>
><br>
> I’m sorry I’m late to this thread, but I’m personally strongly opposed to this. The problem being solved here is so minor that I don’t see a reason to make a change. Further, the proposed syntax is so heavy weight that it will adversely affect readability of the API.<br>
><br>
> -Chris<br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>