> On 20 Jul 2016, at 20:54, Chris Lattner <[email protected]> wrote:
>
>
>> On Jul 20, 2016, at 11:37 AM, Haravikk via swift-evolution
>> <[email protected]> wrote:
>>
>>
>>> On 20 Jul 2016, at 14:55, Tino Heth <[email protected]> wrote:
>>>
>>>
>>>> Am 17.07.2016 um 18:31 schrieb Haravikk <[email protected]>:
>>>>
>>>> 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.
>>> 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.
>>
>> I've created a new pull request for this, you can view the updated file here:
>> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/nnnn-variadics-as-attribute.md
>>
>> 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 =)
>
> I’m sorry I’m late to this thread, but I’m personally strongly opposed to
> this.
I'm similarly late to your reply since somehow I missed it ;)
> The problem being solved here is so minor that I don’t see a reason to make a
> change.
Which problem are you referring to exactly? The core issue of the proposal is
to eliminate an unnecessary custom syntax and use regular function
declarations, but the proposal also extends further than that as detailed in
the advantages section; firstly it also opens passing of arrays to variadic
functions, which seems to be fairly desired despite no proposal that I could
find, but this proposal does so using a regular function definition rather than
bolting on more custom behaviour to variadics. The proposal also details how
the use of an attribute allows selection of any suitable type for handling the
variadics, either to be introduced now or as a future feature, allowing any
ArrayLiteralConvertible or any generic that can be satisfied by an Array to be
used in an implementation, rather than requiring:
func someFunc<I:IteratorProtocol where I.Element == Int>(contentsOf:I)
{ … }
func someFucn(_ values:Int…) { someFunc(contentsOf: values) }
You would just pop the @variadic attribute on the first version.
Again on the future feature front, if we were to get any new variadic features
the use of an attribute should make them easier to add since they could be
added as an attribute parameter. Not that I can think of any, but in future it
would be easy to add say @variadic(min: 1) to set a minimum number of variadic
parameters; not that I want this, it's just the only thing I can think of, but
highlights that an attribute is more extensible.
So while the problem inspiring the proposal is relatively minor, the solution
aims to solve the array passing issue too, while opening up other possibilities
now or in future.
> Further, the proposed syntax is so heavy weight that it will adversely affect
> readability of the API
Is it really so heavy-weight? Obviously it's a bit more effort than three dots,
but it's also declaring an explicit type for your function, which it can also
handle directly in addition to variadic calling.
In my experience the use of @noescape closures is much, much more common than
variadics, yet no-one seems that desperate to introduce a custom syntax just to
make them more lightweight to declare. In fact I could probably count the
number of variadic functions I've seen or used in Swift on one hand, but I use
and benefit from @noescape daily without ever feeling the attribute has been a
burden to declare. This is after all a declaration-site change, anyone actually
using variadics shouldn't notice much of a difference except where the
ambiguity issue strikes, but then that's a problem for any array-passing
extension to variadics I think._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
