[swift-evolution] [Proposal] Variadics as Attribute

[Tony Allevato]

I'm also having trouble getting behind this proposal.

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).

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.

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.

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.


On Wed, Jul 20, 2016 at 1:25 PM Leonardo Pessoa via swift-evolution <
swift-evolution at swift.org> wrote:

> I'm strongly opposed to this too. I'm not only not fond of the
> proposed syntax but I also don't really see how allowing other types
> in variadics will help anything. Also, there may be necessary more
> complex code to support all the extra (or even previously unknown)
> types that could be used with this syntax, making the language much
> more complex.
>
> L
>
>
> On 20 July 2016 at 16:54, Chris Lattner via swift-evolution
> <swift-evolution at swift.org> wrote:
> >
> >> On Jul 20, 2016, at 11:37 AM, Haravikk via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >>
> >>> On 20 Jul 2016, at 14:55, Tino Heth <2th at gmx.de> wrote:
> >>>
> >>>
> >>>> Am 17.07.2016 um 18:31 schrieb Haravikk <swift-evolution at haravikk.me
> >:
> >>>>
> >>>> 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.  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.
> >
> > -Chris
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160720/81486614/attachment.html>