[Proposal] Variadics as Attribute

[Lmpessoa (Leonardo Pessoa)]

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@swift.org> wrote:

On Jul 20, 2016, at 11:37 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 20 Jul 2016, at 14:55, Tino Heth <2th@gmx.de> wrote:

Am 17.07.2016 um 18:31 schrieb Haravikk <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[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@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@swift.org> wrote:
>
>> On Jul 20, 2016, at 11:37 AM, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>>
>>> On 20 Jul 2016, at 14:55, Tino Heth <2th@gmx.de> wrote:
>>>
>>>
>>>> Am 17.07.2016 um 18:31 schrieb Haravikk <swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Tino]

I’m sorry I’m late to this thread, but I’m personally strongly opposed to this.

May I ask a general question:
What implications does this statement have? Is it "spare yourself from unnecessary work, this will never be accepted", or "prepare yourself for a hard review"?

The problem being solved here is so minor that I don’t see a reason to make a change.

There has been a discussion about having something like variadics-splat before (which could be solved with Haravikks idea in an elegant way), and don't you think it is strange to have a third(!) way to declare an array that merely looks like a carryover from C?
I've been quite surprised by the negative reaction, as I think "…" is very similar to the old for-loops and increment/decrement operators which have been phased out already...

Further, the proposed syntax is so heavy weight that it will adversely affect readability of the API.

My impression is that variadics aren't that common in real-world code (at least creating custom variadic functions; and the way they are called wouldn't change), but if you consider them to be such a vital element of Swift:
Afaics, there is no fundamental drawback* if array-arguments could be delivered with variadics-syntax in general — this should make those happy who really like variadics, and would remove an odd special case from method signatures as well.

Best regards,
Tino

* well, there might be the obstacle of "when the hell do you loonies think we shall actually implement all those changes you ask for? There is a deadline for Swift 3, and we already had to drop ABI compatibility, so let us do our job!" ;-)

···

Am 20.07.2016 um 21:54 schrieb Chris Lattner <clattner@apple.com>:

[Haravikk3 (Haravikk)]

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.

···

On 20 Jul 2016, at 20:54, Chris Lattner <clattner@apple.com> wrote:

On Jul 20, 2016, at 11:37 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 20 Jul 2016, at 14:55, Tino Heth <2th@gmx.de> wrote:

Am 17.07.2016 um 18:31 schrieb Haravikk <swift-evolution@haravikk.me>:

[Haravikk3 (Haravikk)]

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.

First; the proposal isn't specifically about enabling other types, I put it in its own section as it's not the primary goal, just a potential bonus now or in future. The main goal is having one function declaration syntax, rather than a feature-specific syntax that creates a need for a type of secondary function, it's about merging the two; so hopefully actually simplifying things in reality by turning variadics into a feature of any function, rather than its own sort of separate thing.

Second, I don't believe it should be overly complex at all; remember all a variadic function really is is a function taking an array, except you don't need to add square brackets. That's basically what it boils down to; it's a way of calling a function such that you can pretend the values you are passing in are arguments, when really they're not. Extending with more types shouldn't really add complexity as they already work with regular functions right now, and I think I've covered the requirements already (a fixed type needs to conform to ArrayLiteralConvertible, while a generic must be able to match an Array).

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.

Can you be more specific about what you mean by variadic generics? Why do you feel these are incompatible with this proposal? The proposal's core after all is about using a single style of function declaration then turning on the ability to call in the variadic style via an attribute, so it seems like it'd be a first step towards most other alternatives anyway IMO as either you use a different attribute to enable the feature, or some kind of generic type to match what you want it to accept.

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.

As I briefly mention at the end of the proposal I'm originally in the ditch variadics entirely camp, as like you I don't see the big deal with just adding square brackets and being explicit about the type. This proposal is intended in part as a compromise, since a lot of people seem to like them.

···

On 20 Jul 2016, at 21:25, Leonardo Pessoa <me@lmpessoa.com> wrote:
On 20 Jul 2016, at 21:40, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:

[Chris_Lattner]

It is hard to say, but it could definitely be either of those. In any case, we’re moving more to a model that proposals need to have fairly strong community support before merging them. This is because we’ve had a number of proposals getting rejected recently, ones that were “obviously” not going to happen.

That said, I specifically worded it that way so that you know it was my person feeling, not the measured opinion of the core team or anyone else. My opinion is shaped by many things, including a significant amount of thinking about the shape of Swift as it is today, along with the tradeoffs involved in adding and removing things. That said, the community sentiment and other core team member opinions frequently change my position on things, so it’s not some invariant - a well developed and very compelling argument is always important for a successful proposal.

-Chris

···

On Jul 21, 2016, at 3:13 AM, Tino Heth <2th@gmx.de> wrote:

Am 20.07.2016 um 21:54 schrieb Chris Lattner <clattner@apple.com>:

I’m sorry I’m late to this thread, but I’m personally strongly opposed to this.

May I ask a general question:
What implications does this statement have? Is it "spare yourself from unnecessary work, this will never be accepted", or "prepare yourself for a hard review”?

[Tino]

I haven't seen a complete proposal, but I managed to remember a link to the last(?) discussion about it:
[Idea] Passing an Array to Variadic Functions <http://article.gmane.org/gmane.comp.lang.swift.evolution/14951&gt;

···

Am 21.07.2016 um 22:11 schrieb Haravikk <swift-evolution@haravikk.me>:

it also opens passing of arrays to variadic functions, which seems to be fairly desired despite no proposal that I could find

[Tino]

Just wanted to ask about the current status — but then saw that there has been a PR already…
It's a pity that there hasn't been the time for a detailed answer, as I still think this is one of the best non-trivial proposals so far.

So, I guess you're discouraged by the backfire, but afaics, there haven't been many people opposing the idea, but rather a lack of interest.
Maybe it's just not the right time, and I hope there are no serious plans to make Swift 3 the last release with breaking changes, so that there will be another possibility to discuss the topic when there is less stress.

What's your opinion on simply allowing variadic-syntax at call site wherever an array is expected? For me, the only real counter-argument has been that "@variadic" is more heavy-weight than three dots, and although I don't agree that this is an issue, "nothing" is obviously as lightweight as possible.

- Tino

[Haravikk3 (Haravikk)]

Oh yeah, in fact the post you linked to was in reply to one of mine arguing that variadics just be removed entirely =)
The full thread and first post are here (if I got the link right): http://thread.gmane.org/gmane.comp.lang.swift.evolution/14807/focus=14951

But no proposal ever came from it, other than this one. I was going to propose removing variadics, but too many people seemed to be against that idea, even though it's by far the cleanest solution, none of the other ideas for array passing seem to have emerged though.

···

On 21 Jul 2016, at 23:05, Tino Heth <2th@gmx.de> wrote:

Am 21.07.2016 um 22:11 schrieb Haravikk <swift-evolution@haravikk.me <mailto:swift-evolution@haravikk.me>>:
it also opens passing of arrays to variadic functions, which seems to be fairly desired despite no proposal that I could find

I haven't seen a complete proposal, but I managed to remember a link to the last(?) discussion about it:
[Idea] Passing an Array to Variadic Functions <http://article.gmane.org/gmane.comp.lang.swift.evolution/14951&gt;

[Haravikk3 (Haravikk)]

Hate to have to bump this myself, but I'm still hoping to get more detailed feedback from those that have made negative comments to clarify or clear up any misunderstandings.

So far the main argument made against the change is that it's more complex than the problem being solved, however this seems to be levelled at a single problem when really this proposal is intended to solve two things; to unify the declaration of regular and variadic functions, and to enable a single function in variadic or array style at the call-site. In essence the latter is a side-effect of the former, as the variadic declaration would no longer be different from any other function. The (relative) complexity is also one of my favourite things as it actually opens up future possibilities too, which I've covered in the proposal.

Otherwise Chris mentioned it being heavyweight, but I'm unclear on whether this was a reference to complexity or just that's more to type in a declaration than three dots. However it's no more heavyweight than say @noescape or @autoclosure, both of which (in my experience at least) are a lot more common than variadics, yet they don't have a custom declaration syntax, but are both features with custom call-site behaviour, so similar to variadics.

I guess I'm resigned to the fact that this isn't likely to make Swift 3 now, but it can still be delivered as an additive change (by leaving the current syntax as a shorthand and deprecating it later) so I'd like to get more feedback before I make any updates to the proposal. It's not easy to gauge from the feedback so far how much of it was read, as I thought the advantages section made a good case, but then I'm not much for proposal writing so fully expect to be responsible for any misunderstandings ;)

···

On 22 Jul 2016, at 12:43, Haravikk <swift-evolution@haravikk.me> wrote:

On 21 Jul 2016, at 23:05, Tino Heth <2th@gmx.de <mailto:2th@gmx.de>> wrote:

Am 21.07.2016 um 22:11 schrieb Haravikk <swift-evolution@haravikk.me <mailto:swift-evolution@haravikk.me>>:
it also opens passing of arrays to variadic functions, which seems to be fairly desired despite no proposal that I could find

I haven't seen a complete proposal, but I managed to remember a link to the last(?) discussion about it:
[Idea] Passing an Array to Variadic Functions <http://article.gmane.org/gmane.comp.lang.swift.evolution/14951&gt;

Oh yeah, in fact the post you linked to was in reply to one of mine arguing that variadics just be removed entirely =)
The full thread and first post are here (if I got the link right): http://thread.gmane.org/gmane.comp.lang.swift.evolution/14807/focus=14951

But no proposal ever came from it, other than this one. I was going to propose removing variadics, but too many people seemed to be against that idea, even though it's by far the cleanest solution, none of the other ideas for array passing seem to have emerged though.