[swift-evolution] [Proposal] Variadics as Attribute

[Leonardo Pessoa]

It is definitely not hard to solve any issues here (if you consider only
the basic variadics). Int... is nothing more than [Int], so essentially

   func doSomething(args : Int...)

is also just

   func doSomething(args : [Int])

We just have to think of it like some form of function overloading and the
compiler can automatically handle that.

As for enabling usage of other types as the result of variadics, I don't
see how that can be a benefit (unless you're just trying to write little
bit less on your own code). You would have to add some extra code on the
compiler to check whether you can use that type for your variadics argument
and may incur in more changes to enable handling different classes
possible. I would also expect to be able to use dictionaries as variadics
with this syntax, and that would be confusing too.

Should this pass like it is, it would not surprise me if my apps take more
time to compile. Now, if the problem is just being able to pass an array to
a variadics argument, my solution is cleaner, incur in less changes to the
language and is backwards compatible.

L

On Friday, 8 July 2016, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On 8 Jul 2016, at 10:31, Pyry Jahkola <pyry.jahkola at iki.fi
> <javascript:_e(%7B%7D,'cvml','pyry.jahkola at iki.fi');>> wrote:
>
> If you take this function for example,
>
>     func printThem(@variadic _ values: [Any])
>
> then what would `values` be in the following calls, and why?
>
>     printThem() // clearly []
>     printThem(1) // clearly [1]
>     printThem(1, 2) // clearly [1, 2]
>     printThem([1], [2]) // clearly [[1], [2]]
>     printThem([]) // [] or [[]], which one?
>     printThem([1]) // [1] or [[1]]?
>     printThem([1, 2]) // [1, 2] or [[1, 2]]?
>
>
> I think it would be less painful a change (i.e. can be delayed past Swift
> 3) if we just augment what we have (the `...` argument declaration syntax)
> with a way to expand an Array in place of a variadic argument:
>
>     func printThem(_ values: Any...)
>
>     printThem(1) // values == [1]
>     printThem([1]) // values == [[1]]
>     // Possible expansion postfix syntax:
>     printThem([1]...) // values == [1]
>     // Expanding a non-array sequence:
>     let things: Set<Int> = [1, 2, 3]
>     printThem(Array(things)...)
>
>
> Good point, but actually these don't seem mutually exclusive; the three
> problem examples you gave could be resolved either by requiring the extra
> set of square brackets for clarity, and/or some kind of expansion like you
> suggest, either an operator or even possibly repurposing the attribute at
> the call-site for consistency. For example:
>
> printThem([1]) // warning, ambiguous
> printThem([[1]])// non-variadic
> printThem(@variadic [1]) // absolutely definitely 100% a variadic call
> printThem([1],) // alternative to an operator/attribute for
> variadic disambiguation?
>
> Thoughts?
>
>
> On 8 Jul 2016, at 10:42, Tino Heth <2th at gmx.de
> <javascript:_e(%7B%7D,'cvml','2th at gmx.de');>> wrote:
> I'm not sure if the timing of this proposal is coincidence (I recently
> revived a discussion to remove variadics)
>
>
> It is definitely not a coincidence ;)
> I participated in the discussion on removal in the past and actually
> posted a preliminary version of this there, so the recent posts reminded me
> to put it into a proper proposal. Personally like some I'd just remove the
> feature completely, but it seems enough people want to keep it that it's
> worth exploring alternatives as there seems a fairly even mix of those for
> and against the feature.
>


-- 
L
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160708/88407053/attachment.html>