1

I'm posting this as a new discussion topic for my earlier proposal of Variadics as an Attribute. I would have reused the old topic but I have no idea how to do that on a mailing list once the messages are gone (I don't keep them for long); I'm looking forward to the possible switch to Discourse!

The idea behind the proposal is fairly simple; to do away with the current unique syntax for declaring variadic functions/methods, while retaining the ability to call methods in the same way. In other words, instead of declaring a method with an ellipsis, you would declare it just like any other method, but add the @variadic attribute, enabling the ability to call it just like you would call a variadic now.

Since this isn't strictly a code-breaking change (existing code can be converted automatically) I'm unsure of when to issue a new pull request, so I'll stick with a discussion to hammer out any lingering issues with the proposal for just now. Here it is:

https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/nnnn-variadics-as-attribute.md

Variadics as Attribute

Proposal: SE-NNNN <https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md&gt;
Author: Haravikk <https://github.com/haravikk&gt;
Status: Awaiting review
Review manager: TBD

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#introduction&gt;Introduction

This proposal seeks to redesign the current, unique variadic function declaration syntax to use an attribute instead, with a goal of unifying standard and variadic function declarations.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#motivation&gt;Motivation

Variadics are essentially a call-site feature enabling a function to be called as if it is being provided with multiple arguments, rather than a single list argument. However instead of being implemented as some kind of switch, variadics have a unique declaration syntax that separates them uncessarily from standard function declarations. Currently this also means that redundancy is required in order to allow a function to be called both with an explicit array, and in the variadic style.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#proposed-solution&gt;Proposed solution

To unify both regular and variadic function declarations this proposal seeks to replace the unique trailing elipsis declaration syntax with a new @variadic attribute on regular function declarations, enabling optional variadic syntax at the call site.

In short this proposal would replace:

func someFunc(_ values:Int...) { … }
With the following:

func someFunc(_ values:@variadic [Int]) { … }

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#detailed-design&gt;Detailed design

The trailing elipsis declaration syntax will be removed, with a fixit providing a replacement to the new attribute-based syntax. The new @variadic attribute can be placed on any one function parameter with a type of Array<Foo> (or [Foo]), enabling the optional use of variadic declaration at the call site.

For example:

func someFunc(_ values:@variadic [Int]) { … }
Can be called in any of the following forms:

someFunc(1, 2, 3, 4, 5) // Fixed length variadic call
someFunc([1, 2, 3, 4, 5]) // Fixed length array call
someFunc(foo) // Dynamic array call passing the Array variable foo

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#advantages&gt;Advantages

Unifies standard and variadic function declarations, eliminating a unique syntax that is arguably unnecessary.
The type of the variadic parameter is absolutely explicit.
Enables calling of a variadic function with dynamic arrays, without the need for additional special syntax.
No redundant overloads to enable both call styles (one declaration provides both).
Enables further extension to support more collection types now or in future (see Proposed Extension below).
Moves the variadic feature declaration from syntax into the attributes list, which should aid discoverability (and simplify syntax very slightly).
The attribute is more explicit about what it does (provides a name that can be searched).

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#ambiguity&gt;Ambiguity

One technical issue with this change is the introduction of ambiguity as follows:

someFunc(_ values:@variadic [Any]) { … }
someFunc([1]) // Is this an array call of [1] or a variadic call of [[1]]?
someFunc(foo) // If foo is an array, is this an array call of foo, or a variadic call of [foo]?
However, this issue is only exhibited when the type of variadic is Any (or another type that can represent both an array of elements and the elements themselves) and only when there is possibly only a single argument.

The proposed solution to this is to reuse the new @variadic attribute, plus a @nonVariadic attribute*, enabling disambiguation like so:

someFunc(@variadic [1]) // Unambiguously a variadic call of [[1]]
someFunc(@nonVariadic [1]) // Unambiguously an array call of [1]
someFunc(@variadic foo) // Unambiguously a variadic call of [foo]
In the variadic case it could also be possible to use a trailing comma for disambiguation like so:

someFunc([1],) // Unambiguously a varaidic call of [[1]]
someFunc(foo,) // Unambiguously a variadic call of [foo]
*These attributes could instead be compiler directives if that is more appropriate.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#impact-on-existing-code&gt;Impact on existing code

All existing variadic function function declarations will be invalidated, either being replaced or producing a fixit to perform conversion like so:

func someFunc(_ values:Int...) // Before
func someFunc(_ values:@variadic [Int]) // After

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#proposed-extension&gt;Proposed Extension

One other advantage of the use of an attribute is the possibility of allowing variadic enabled functions to accept a wider range of parameter types. For example, the above examples could be implemented instead like so:

func someFunc(_ values:@variadic MyArrayLiteralConvertible<Int>) { … } // Type conforming to ArrayLiteralConvertible
func someFunc<I:IteratorProtocol where I.Element == Int>(_ values:@variadic I) { … } // Implementation supports all single and multi-pass types
func someFunc<S:Sequence where S.Iterator.Element == Int>(_ values:@variadic S) { … } // Implementation supports all (probably) multi-pass types
func someFunc<C:Collection where C.Iterator.Element == Int>(_ values:@variadic C) { … } // Implementation supports all guaranteed multi-pass, indexable types with known size
When a specific type is defined it must conform to ArrayLiteralConvertible to enable variadic calls, while generic conformances must be capable of being satisfied by an Array when called in variadic style. For example, the latter three examples would all receive an [Int] when called in variadic style, but can accept any suitable iterator, sequence or collection when called dynamically. In other words, when a function is called in variadic style it is always passed an Arrayunless its type is ArrayLiteralConvertible, so its supported type(s) must support this.

This extension has been moved into its own section as it is not critical to the proposal, however it does represent an advantage of the attribute based approach, and would be desirable to have if implementing it is sufficiently easy for it to be done at the same time.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#alternatives-considered&gt;Alternatives considered

One alternative often mentioned is simply enabling the existing variadic declarations to be called with an array. However, this has the same issue with ambiguity to resolve, and leaves variadics as their own category of function, rather than unifying them with ordinary functions.

It is possible to both add the @variadic attribute and retain the current syntax as a shorthand, however if the proposed extension is implemented this would discourage consideration of the best collection type to use, and in general it would remove one advantage in removing this extraneous syntax.

The nuclear option is to remove variadics entirely; this is the preference of some (myself included) as it eliminates the inherent ambiguity of variadics in general, forcing explicit use of arrays and other types with no need for limitations, however there is sufficient support for variadics now that they exist that this option is unlikely to succeed.

1 Like
2

Immediate followup, but is there something wrong with the gmane site that we've been using to provide links to mailing list discussions?
I can't seem to get a list of recent topics so I can find out what the new discussion link should be.

···

On 15 Feb 2017, at 11:38, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

I'm posting this as a new discussion topic for my earlier proposal of Variadics as an Attribute. I would have reused the old topic but I have no idea how to do that on a mailing list once the messages are gone (I don't keep them for long); I'm looking forward to the possible switch to Discourse!

The idea behind the proposal is fairly simple; to do away with the current unique syntax for declaring variadic functions/methods, while retaining the ability to call methods in the same way. In other words, instead of declaring a method with an ellipsis, you would declare it just like any other method, but add the @variadic attribute, enabling the ability to call it just like you would call a variadic now.

Since this isn't strictly a code-breaking change (existing code can be converted automatically) I'm unsure of when to issue a new pull request, so I'll stick with a discussion to hammer out any lingering issues with the proposal for just now. Here it is:

https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/nnnn-variadics-as-attribute.md

Variadics as Attribute

Proposal: SE-NNNN <https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md&gt;
Author: Haravikk <https://github.com/haravikk&gt;
Status: Awaiting review
Review manager: TBD

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#introduction&gt;Introduction

This proposal seeks to redesign the current, unique variadic function declaration syntax to use an attribute instead, with a goal of unifying standard and variadic function declarations.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#motivation&gt;Motivation

Variadics are essentially a call-site feature enabling a function to be called as if it is being provided with multiple arguments, rather than a single list argument. However instead of being implemented as some kind of switch, variadics have a unique declaration syntax that separates them uncessarily from standard function declarations. Currently this also means that redundancy is required in order to allow a function to be called both with an explicit array, and in the variadic style.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#proposed-solution&gt;Proposed solution

To unify both regular and variadic function declarations this proposal seeks to replace the unique trailing elipsis declaration syntax with a new @variadic attribute on regular function declarations, enabling optional variadic syntax at the call site.

In short this proposal would replace:

func someFunc(_ values:Int...) { … }
With the following:

func someFunc(_ values:@variadic [Int]) { … }

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#detailed-design&gt;Detailed design

The trailing elipsis declaration syntax will be removed, with a fixit providing a replacement to the new attribute-based syntax. The new @variadic attribute can be placed on any one function parameter with a type of Array<Foo> (or [Foo]), enabling the optional use of variadic declaration at the call site.

For example:

func someFunc(_ values:@variadic [Int]) { … }
Can be called in any of the following forms:

someFunc(1, 2, 3, 4, 5) // Fixed length variadic call
someFunc([1, 2, 3, 4, 5]) // Fixed length array call
someFunc(foo) // Dynamic array call passing the Array variable foo

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#advantages&gt;Advantages

Unifies standard and variadic function declarations, eliminating a unique syntax that is arguably unnecessary.
The type of the variadic parameter is absolutely explicit.
Enables calling of a variadic function with dynamic arrays, without the need for additional special syntax.
No redundant overloads to enable both call styles (one declaration provides both).
Enables further extension to support more collection types now or in future (see Proposed Extension below).
Moves the variadic feature declaration from syntax into the attributes list, which should aid discoverability (and simplify syntax very slightly).
The attribute is more explicit about what it does (provides a name that can be searched).

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#ambiguity&gt;Ambiguity

One technical issue with this change is the introduction of ambiguity as follows:

someFunc(_ values:@variadic [Any]) { … }
someFunc([1]) // Is this an array call of [1] or a variadic call of [[1]]?
someFunc(foo) // If foo is an array, is this an array call of foo, or a variadic call of [foo]?
However, this issue is only exhibited when the type of variadic is Any (or another type that can represent both an array of elements and the elements themselves) and only when there is possibly only a single argument.

The proposed solution to this is to reuse the new @variadic attribute, plus a @nonVariadic attribute*, enabling disambiguation like so:

someFunc(@variadic [1]) // Unambiguously a variadic call of [[1]]
someFunc(@nonVariadic [1]) // Unambiguously an array call of [1]
someFunc(@variadic foo) // Unambiguously a variadic call of [foo]
In the variadic case it could also be possible to use a trailing comma for disambiguation like so:

someFunc([1],) // Unambiguously a varaidic call of [[1]]
someFunc(foo,) // Unambiguously a variadic call of [foo]
*These attributes could instead be compiler directives if that is more appropriate.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#impact-on-existing-code&gt;Impact on existing code

All existing variadic function function declarations will be invalidated, either being replaced or producing a fixit to perform conversion like so:

func someFunc(_ values:Int...) // Before
func someFunc(_ values:@variadic [Int]) // After

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#proposed-extension&gt;Proposed Extension

One other advantage of the use of an attribute is the possibility of allowing variadic enabled functions to accept a wider range of parameter types. For example, the above examples could be implemented instead like so:

func someFunc(_ values:@variadic MyArrayLiteralConvertible<Int>) { … } // Type conforming to ArrayLiteralConvertible
func someFunc<I:IteratorProtocol where I.Element == Int>(_ values:@variadic I) { … } // Implementation supports all single and multi-pass types
func someFunc<S:Sequence where S.Iterator.Element == Int>(_ values:@variadic S) { … } // Implementation supports all (probably) multi-pass types
func someFunc<C:Collection where C.Iterator.Element == Int>(_ values:@variadic C) { … } // Implementation supports all guaranteed multi-pass, indexable types with known size
When a specific type is defined it must conform to ArrayLiteralConvertible to enable variadic calls, while generic conformances must be capable of being satisfied by an Array when called in variadic style. For example, the latter three examples would all receive an [Int] when called in variadic style, but can accept any suitable iterator, sequence or collection when called dynamically. In other words, when a function is called in variadic style it is always passed an Arrayunless its type is ArrayLiteralConvertible, so its supported type(s) must support this.

This extension has been moved into its own section as it is not critical to the proposal, however it does represent an advantage of the attribute based approach, and would be desirable to have if implementing it is sufficiently easy for it to be done at the same time.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#alternatives-considered&gt;Alternatives considered

One alternative often mentioned is simply enabling the existing variadic declarations to be called with an array. However, this has the same issue with ambiguity to resolve, and leaves variadics as their own category of function, rather than unifying them with ordinary functions.

It is possible to both add the @variadic attribute and retain the current syntax as a shorthand, however if the proposed extension is implemented this would discourage consideration of the best collection type to use, and in general it would remove one advantage in removing this extraneous syntax.

The nuclear option is to remove variadics entirely; this is the preference of some (myself included) as it eliminates the inherent ambiguity of variadics in general, forcing explicit use of arrays and other types with no need for limitations, however there is sufficient support for variadics now that they exist that this option is unlikely to succeed.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

–1 for me, I’ll explain in a moment.

To help you find the old topic you can use the proof-of-concept Discourse setup from Nate Cook: http://discourse.natecook.com/t/proposal-variadics-as-attribute/2075/20

The link above also reflects Chris Lattners opinion on this topic.

I gave the topic a down vote not because I don’t like the proposal, but because I personally see variadics go into the direction of tuples. Especially I’d love to see some more talk about tuples in combination of generic variadics (see here: swift/GenericsManifesto.md at main · apple/swift · GitHub).

There is a lot of design overlap. That is the reason why I think we should vision variadics as a whole in its future rather than simply repaint … postfix to a type annotation keyword @variadics. This will only close the doors for some features we might want to add in a future version of Swift.

···

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 12:43:49, Haravikk via swift-evolution (swift-evolution@swift.org) schrieb:

Immediate followup, but is there something wrong with the gmane site that we've been using to provide links to mailing list discussions?
I can't seem to get a list of recent topics so I can find out what the new discussion link should be.

On 15 Feb 2017, at 11:38, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

I'm posting this as a new discussion topic for my earlier proposal of Variadics as an Attribute. I would have reused the old topic but I have no idea how to do that on a mailing list once the messages are gone (I don't keep them for long); I'm looking forward to the possible switch to Discourse!

The idea behind the proposal is fairly simple; to do away with the current unique syntax for declaring variadic functions/methods, while retaining the ability to call methods in the same way. In other words, instead of declaring a method with an ellipsis, you would declare it just like any other method, but add the @variadic attribute, enabling the ability to call it just like you would call a variadic now.

Since this isn't strictly a code-breaking change (existing code can be converted automatically) I'm unsure of when to issue a new pull request, so I'll stick with a discussion to hammer out any lingering issues with the proposal for just now. Here it is:

https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/nnnn-variadics-as-attribute.md

Variadics as Attribute
Proposal: SE-NNNN
Author: Haravikk
Status: Awaiting review
Review manager: TBD
Introduction

This proposal seeks to redesign the current, unique variadic function declaration syntax to use an attribute instead, with a goal of unifying standard and variadic function declarations.

Motivation

Variadics are essentially a call-site feature enabling a function to be called as if it is being provided with multiple arguments, rather than a single list argument. However instead of being implemented as some kind of switch, variadics have a unique declaration syntax that separates them uncessarily from standard function declarations. Currently this also means that redundancy is required in order to allow a function to be called both with an explicit array, and in the variadic style.

Proposed solution

To unify both regular and variadic function declarations this proposal seeks to replace the unique trailing elipsis declaration syntax with a new @variadic attribute on regular function declarations, enabling optional variadic syntax at the call site.

In short this proposal would replace:

func someFunc(_ values:Int...) { … }
With the following:

func someFunc(_ values:@variadic [Int]) { … }
Detailed design

The trailing elipsis declaration syntax will be removed, with a fixit providing a replacement to the new attribute-based syntax. The new @variadic attribute can be placed on any one function parameter with a type of Array<Foo> (or [Foo]), enabling the optional use of variadic declaration at the call site.

For example:

func someFunc(_ values:@variadic [Int]) { … }
Can be called in any of the following forms:

someFunc(1, 2, 3, 4, 5) // Fixed length variadic call
someFunc([1, 2, 3, 4, 5]) // Fixed length array call
someFunc(foo) // Dynamic array call passing the Array variable foo
Advantages

Unifies standard and variadic function declarations, eliminating a unique syntax that is arguably unnecessary.
The type of the variadic parameter is absolutely explicit.
Enables calling of a variadic function with dynamic arrays, without the need for additional special syntax.
No redundant overloads to enable both call styles (one declaration provides both).
Enables further extension to support more collection types now or in future (see Proposed Extension below).
Moves the variadic feature declaration from syntax into the attributes list, which should aid discoverability (and simplify syntax very slightly).
The attribute is more explicit about what it does (provides a name that can be searched).
Ambiguity

One technical issue with this change is the introduction of ambiguity as follows:

someFunc(_ values:@variadic [Any]) { … }
someFunc([1]) // Is this an array call of [1] or a variadic call of [[1]]?
someFunc(foo) // If foo is an array, is this an array call of foo, or a variadic call of [foo]?
However, this issue is only exhibited when the type of variadic is Any (or another type that can represent both an array of elements and the elements themselves) and only when there is possibly only a single argument.

The proposed solution to this is to reuse the new @variadic attribute, plus a @nonVariadic attribute*, enabling disambiguation like so:

someFunc(@variadic [1]) // Unambiguously a variadic call of [[1]]
someFunc(@nonVariadic [1]) // Unambiguously an array call of [1]
someFunc(@variadic foo) // Unambiguously a variadic call of [foo]
In the variadic case it could also be possible to use a trailing comma for disambiguation like so:

someFunc([1],) // Unambiguously a varaidic call of [[1]]
someFunc(foo,) // Unambiguously a variadic call of [foo]
*These attributes could instead be compiler directives if that is more appropriate.

Impact on existing code

All existing variadic function function declarations will be invalidated, either being replaced or producing a fixit to perform conversion like so:

func someFunc(_ values:Int...) // Before
func someFunc(_ values:@variadic [Int]) // After
Proposed Extension

One other advantage of the use of an attribute is the possibility of allowing variadic enabled functions to accept a wider range of parameter types. For example, the above examples could be implemented instead like so:

func someFunc(_ values:@variadic MyArrayLiteralConvertible<Int>) { … } // Type conforming to ArrayLiteralConvertible
func someFunc<I:IteratorProtocol where I.Element == Int>(_ values:@variadic I) { … } // Implementation supports all single and multi-pass types
func someFunc<S:Sequence where S.Iterator.Element == Int>(_ values:@variadic S) { … } // Implementation supports all (probably) multi-pass types
func someFunc<C:Collection where C.Iterator.Element == Int>(_ values:@variadic C) { … } // Implementation supports all guaranteed multi-pass, indexable types with known size
When a specific type is defined it must conform to ArrayLiteralConvertible to enable variadic calls, while generic conformances must be capable of being satisfied by an Array when called in variadic style. For example, the latter three examples would all receive an [Int] when called in variadic style, but can accept any suitable iterator, sequence or collection when called dynamically. In other words, when a function is called in variadic style it is always passed an Arrayunless its type is ArrayLiteralConvertible, so its supported type(s) must support this.

This extension has been moved into its own section as it is not critical to the proposal, however it does represent an advantage of the attribute based approach, and would be desirable to have if implementing it is sufficiently easy for it to be done at the same time.

Alternatives considered

One alternative often mentioned is simply enabling the existing variadic declarations to be called with an array. However, this has the same issue with ambiguity to resolve, and leaves variadics as their own category of function, rather than unifying them with ordinary functions.

It is possible to both add the @variadic attribute and retain the current syntax as a shorthand, however if the proposed extension is implemented this would discourage consideration of the best collection type to use, and in general it would remove one advantage in removing this extraneous syntax.

The nuclear option is to remove variadics entirely; this is the preference of some (myself included) as it eliminates the inherent ambiguity of variadics in general, forcing explicit use of arrays and other types with no need for limitations, however there is sufficient support for variadics now that they exist that this option is unlikely to succeed.
_______________________________________________
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

4

+1

I don't see tuples as a better solution for this without substantial work.
Even after all of that work, I am not convinced that tuples would be a
better solution.

···

On Wed, Feb 15, 2017 at 7:16 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:

–1 for me, I’ll explain in a moment.

To help you find the old topic you can use the *proof-of-concept*
Discourse setup from Nate Cook: http://discourse.natecook.com/
t/proposal-variadics-as-attribute/2075/20

The link above also reflects Chris Lattners opinion on this topic.
------------------------------

I gave the topic a down vote not because I don’t like the proposal, but
because I personally see variadics go into the direction of tuples.
Especially I’d love to see some more talk about tuples in combination of
generic variadics (see here: Apple · GitHub
swift/blob/master/docs/GenericsManifesto.md#variadic-generics).

There is a lot of design overlap. That is the reason why I think we should
vision variadics as a whole in its future rather than simply repaint …
postfix to a type annotation keyword @variadics. This will only close the
doors for some features we might want to add in a future version of Swift.

--
Adrian Zubarev
Sent with Airmail

Am 15. Februar 2017 um 12:43:49, Haravikk via swift-evolution (
swift-evolution@swift.org) schrieb:

Immediate followup, but is there something wrong with the gmane site that
we've been using to provide links to mailing list discussions?
I can't seem to get a list of recent topics so I can find out what the new
discussion link should be.

On 15 Feb 2017, at 11:38, Haravikk via swift-evolution < > swift-evolution@swift.org> wrote:

I'm posting this as a new discussion topic for my earlier proposal of
Variadics as an Attribute. I would have reused the old topic but I have no
idea how to do that on a mailing list once the messages are gone (I don't
keep them for long); I'm looking forward to the possible switch to
Discourse!

The idea behind the proposal is fairly simple; to do away with the current
unique syntax for declaring variadic functions/methods, while retaining the
ability to call methods in the same way. In other words, instead of
declaring a method with an ellipsis, you would declare it just like any
other method, but add the @variadic attribute, enabling the ability to call
it just like you would call a variadic now.

Since this isn't strictly a code-breaking change (existing code can be
converted automatically) I'm unsure of when to issue a new pull request, so
I'll stick with a discussion to hammer out any lingering issues with the
proposal for just now. Here it is:

https://github.com/Haravikk/swift-evolution/blob/
1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/nnnn-
variadics-as-attribute.md

Variadics as Attribute

   - Proposal: SE-NNNN
   <https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md&gt;
   - Author: Haravikk <https://github.com/haravikk&gt;
   - Status: Awaiting review
   - Review manager: TBD

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#introduction&gt;
Introduction

This proposal seeks to redesign the current, unique variadic function
declaration syntax to use an attribute instead, with a goal of unifying
standard and variadic function declarations.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#motivation&gt;
Motivation

Variadics are essentially a call-site feature enabling a function to be
called as if it is being provided with multiple arguments, rather than a
single list argument. However instead of being implemented as some kind of
switch, variadics have a unique declaration syntax that separates them
uncessarily from standard function declarations. Currently this also means
that redundancy is required in order to allow a function to be called both
with an explicit array, and in the variadic style.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#proposed-solution&gt;Proposed
solution

To unify both regular and variadic function declarations this proposal
seeks to replace the unique trailing elipsis declaration syntax with a new
@variadic attribute on regular function declarations, enabling optional
variadic syntax at the call site.

In short this proposal would replace:

func someFunc(_ values:Int...) { … }

With the following:

func someFunc(_ values:@variadic [Int]) { … }

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#detailed-design&gt;Detailed
design

The trailing elipsis declaration syntax will be removed, with a fixit
providing a replacement to the new attribute-based syntax. The new
@variadic attribute can be placed on any one function parameter with a
type of Array<Foo> (or [Foo]), enabling the optional use of variadic
declaration at the call site.

For example:

func someFunc(_ values:@variadic [Int]) { … }

Can be called in any of the following forms:

someFunc(1, 2, 3, 4, 5) // Fixed length variadic call
someFunc([1, 2, 3, 4, 5]) // Fixed length array call
someFunc(foo) // Dynamic array call passing the Array variable foo

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#advantages&gt;
Advantages

   1. Unifies standard and variadic function declarations, eliminating a
   unique syntax that is arguably unnecessary.
   2. The type of the variadic parameter is absolutely explicit.
   3. Enables calling of a variadic function with dynamic arrays, without
   the need for additional special syntax.
   4. No redundant overloads to enable both call styles (one declaration
   provides both).
   5. Enables further extension to support more collection types now or
   in future (see Proposed Extension below).
   6. Moves the variadic feature declaration from syntax into the
   attributes list, which should aid discoverability (and simplify syntax very
   slightly).
   7. The attribute is more explicit about what it does (provides a name
   that can be searched).

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#ambiguity&gt;
Ambiguity

One technical issue with this change is the introduction of ambiguity as
follows:

someFunc(_ values:@variadic [Any]) { … }
someFunc([1]) // Is this an array call of [1] or a variadic call of [[1]]?
someFunc(foo) // If foo is an array, is this an array call of foo, or a variadic call of [foo]?

However, this issue is only exhibited when the type of variadic is Any (or
another type that can represent both an array of elements and the elements
themselves) and only when there is possibly only a single argument.

The proposed solution to this is to reuse the new @variadic attribute,
plus a @nonVariadic attribute*, enabling disambiguation like so:

someFunc(@variadic [1]) // Unambiguously a variadic call of [[1]]
someFunc(@nonVariadic [1]) // Unambiguously an array call of [1]
someFunc(@variadic foo) // Unambiguously a variadic call of [foo]

In the variadic case it could also be possible to use a trailing comma for
disambiguation like so:

someFunc([1],) // Unambiguously a varaidic call of [[1]]
someFunc(foo,) // Unambiguously a variadic call of [foo]

*These attributes could instead be compiler directives if that is more
appropriate.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#impact-on-existing-code&gt;Impact
on existing code

All existing variadic function function declarations will be invalidated,
either being replaced or producing a fixit to perform conversion like so:

func someFunc(_ values:Int...) // Before
func someFunc(_ values:@variadic [Int]) // After

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#proposed-extension&gt;Proposed
Extension

One other advantage of the use of an attribute is the possibility of
allowing variadic enabled functions to accept a wider range of parameter
types. For example, the above examples could be implemented instead like so:

func someFunc(_ values:@variadic MyArrayLiteralConvertible<Int>) { … } // Type conforming to ArrayLiteralConvertible
func someFunc<I:IteratorProtocol where I.Element == Int>(_ values:@variadic I) { … } // Implementation supports all single and multi-pass types
func someFunc<S:Sequence where S.Iterator.Element == Int>(_ values:@variadic S) { … } // Implementation supports all (probably) multi-pass types
func someFunc<C:Collection where C.Iterator.Element == Int>(_ values:@variadic C) { … } // Implementation supports all guaranteed multi-pass, indexable types with known size

When a specific type is defined it must conform to ArrayLiteralConvertible to
enable variadic calls, while generic conformances must be capable of being
satisfied by an Array when called in variadic style. For example, the
latter three examples would all receive an [Int] when called in variadic
style, but can accept any suitable iterator, sequence or collection when
called dynamically. In other words, when a function is called in variadic
style it is always passed an Arrayunless its type is
ArrayLiteralConvertible, so its supported type(s) must support this.

This extension has been moved into its own section as it is not critical
to the proposal, however it does represent an advantage of the attribute
based approach, and would be desirable to have if implementing it is
sufficiently easy for it to be done at the same time.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#alternatives-considered&gt;Alternatives
considered

One alternative often mentioned is simply enabling the existing variadic
declarations to be called with an array. However, this has the same issue
with ambiguity to resolve, and leaves variadics as their own category of
function, rather than unifying them with ordinary functions.

It is possible to both add the @variadic attribute and retain the current
syntax as a shorthand, however if the proposed extension is implemented
this would discourage consideration of the best collection type to use, and
in general it would remove one advantage in removing this extraneous syntax.
The nuclear option is to remove variadics entirely; this is the preference
of some (myself included) as it eliminates the inherent ambiguity of
variadics in general, forcing explicit use of arrays and other types with
no need for limitations, however there is sufficient support for variadics
now that they exist that this option is unlikely to succeed.
_______________________________________________
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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

I gave the topic a down vote not because I don’t like the proposal, but because I personally see variadics go into the direction of tuples. Especially I’d love to see some more talk about tuples in combination of generic variadics (see here: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#variadic-generics\).

There is a lot of design overlap. That is the reason why I think we should vision variadics as a whole in its future rather than simply repaint … postfix to a type annotation keyword @variadics. This will only close the doors for some features we might want to add in a future version of Swift.

This seems like an entirely separate feature to me; unless the intention is to go back to the old style of treating function arguments as a tuple I don't see why they should need to be related?

Variable-width tuples would still be compiled down to fixed widths at some point (based on the number of types you pass).
Variadic functions however are just syntactic sugar for passing an array, currently minus the ability to actually pass an array.

I don't think they're similar at all; repurposing of ellipsis to variadic generics/tuples isn't something I'm opposed to (though I still don't like the ambiguity with ranges), because to me it doesn't seem like an overlapping feature at all.

Put another way; variadic generics is a way to allow developers to specify multiple types and arbitrary-width tuples, variadic functions just let developers call a method without using square braces. Why does the latter warrant a unique syntax that effectively creates a special class of function lacking the ability to specify collection type?

···

On 15 Feb 2017, at 12:16, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Am 15. Februar 2017 um 12:43:49, Haravikk via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

Immediate followup, but is there something wrong with the gmane site that we've been using to provide links to mailing list discussions?
I can't seem to get a list of recent topics so I can find out what the new discussion link should be.

On 15 Feb 2017, at 11:38, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I'm posting this as a new discussion topic for my earlier proposal of Variadics as an Attribute. I would have reused the old topic but I have no idea how to do that on a mailing list once the messages are gone (I don't keep them for long); I'm looking forward to the possible switch to Discourse!

The idea behind the proposal is fairly simple; to do away with the current unique syntax for declaring variadic functions/methods, while retaining the ability to call methods in the same way. In other words, instead of declaring a method with an ellipsis, you would declare it just like any other method, but add the @variadic attribute, enabling the ability to call it just like you would call a variadic now.

Since this isn't strictly a code-breaking change (existing code can be converted automatically) I'm unsure of when to issue a new pull request, so I'll stick with a discussion to hammer out any lingering issues with the proposal for just now. Here it is:

https://github.com/Haravikk/swift-evolution/blob/1d3c09f1c6f3e6dc502ef84538d197a02bed904e/proposals/nnnn-variadics-as-attribute.md

Variadics as Attribute
Proposal: SE-NNNN <https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md&gt;
Author: Haravikk <https://github.com/haravikk&gt;
Status: Awaiting review
Review manager: TBD
<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#introduction&gt;Introduction

This proposal seeks to redesign the current, unique variadic function declaration syntax to use an attribute instead, with a goal of unifying standard and variadic function declarations.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#motivation&gt;Motivation

Variadics are essentially a call-site feature enabling a function to be called as if it is being provided with multiple arguments, rather than a single list argument. However instead of being implemented as some kind of switch, variadics have a unique declaration syntax that separates them uncessarily from standard function declarations. Currently this also means that redundancy is required in order to allow a function to be called both with an explicit array, and in the variadic style.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#proposed-solution&gt;Proposed solution

To unify both regular and variadic function declarations this proposal seeks to replace the unique trailing elipsis declaration syntax with a new @variadic attribute on regular function declarations, enabling optional variadic syntax at the call site.

In short this proposal would replace:

func someFunc(_ values:Int...) { … }
With the following:

func someFunc(_ values:@variadic [Int]) { … }
<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#detailed-design&gt;Detailed design

The trailing elipsis declaration syntax will be removed, with a fixit providing a replacement to the new attribute-based syntax. The new @variadic attribute can be placed on any one function parameter with a type of Array<Foo> (or [Foo]), enabling the optional use of variadic declaration at the call site.

For example:

func someFunc(_ values:@variadic [Int]) { … }
Can be called in any of the following forms:

someFunc(1, 2, 3, 4, 5) // Fixed length variadic call
someFunc([1, 2, 3, 4, 5]) // Fixed length array call
someFunc(foo) // Dynamic array call passing the Array variable foo
<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#advantages&gt;Advantages

Unifies standard and variadic function declarations, eliminating a unique syntax that is arguably unnecessary.
The type of the variadic parameter is absolutely explicit.
Enables calling of a variadic function with dynamic arrays, without the need for additional special syntax.
No redundant overloads to enable both call styles (one declaration provides both).
Enables further extension to support more collection types now or in future (see Proposed Extension below).
Moves the variadic feature declaration from syntax into the attributes list, which should aid discoverability (and simplify syntax very slightly).
The attribute is more explicit about what it does (provides a name that can be searched).
<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#ambiguity&gt;Ambiguity

One technical issue with this change is the introduction of ambiguity as follows:

someFunc(_ values:@variadic [Any]) { … }
someFunc([1]) // Is this an array call of [1] or a variadic call of [[1]]?
someFunc(foo) // If foo is an array, is this an array call of foo, or a variadic call of [foo]?
However, this issue is only exhibited when the type of variadic is Any (or another type that can represent both an array of elements and the elements themselves) and only when there is possibly only a single argument.

The proposed solution to this is to reuse the new @variadic attribute, plus a @nonVariadic attribute*, enabling disambiguation like so:

someFunc(@variadic [1]) // Unambiguously a variadic call of [[1]]
someFunc(@nonVariadic [1]) // Unambiguously an array call of [1]
someFunc(@variadic foo) // Unambiguously a variadic call of [foo]
In the variadic case it could also be possible to use a trailing comma for disambiguation like so:

someFunc([1],) // Unambiguously a varaidic call of [[1]]
someFunc(foo,) // Unambiguously a variadic call of [foo]
*These attributes could instead be compiler directives if that is more appropriate.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#impact-on-existing-code&gt;Impact on existing code

All existing variadic function function declarations will be invalidated, either being replaced or producing a fixit to perform conversion like so:

func someFunc(_ values:Int...) // Before
func someFunc(_ values:@variadic [Int]) // After
<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#proposed-extension&gt;Proposed Extension

One other advantage of the use of an attribute is the possibility of allowing variadic enabled functions to accept a wider range of parameter types. For example, the above examples could be implemented instead like so:

func someFunc(_ values:@variadic MyArrayLiteralConvertible<Int>) { … } // Type conforming to ArrayLiteralConvertible
func someFunc<I:IteratorProtocol where I.Element == Int>(_ values:@variadic I) { … } // Implementation supports all single and multi-pass types
func someFunc<S:Sequence where S.Iterator.Element == Int>(_ values:@variadic S) { … } // Implementation supports all (probably) multi-pass types
func someFunc<C:Collection where C.Iterator.Element == Int>(_ values:@variadic C) { … } // Implementation supports all guaranteed multi-pass, indexable types with known size
When a specific type is defined it must conform to ArrayLiteralConvertible to enable variadic calls, while generic conformances must be capable of being satisfied by an Array when called in variadic style. For example, the latter three examples would all receive an [Int] when called in variadic style, but can accept any suitable iterator, sequence or collection when called dynamically. In other words, when a function is called in variadic style it is always passed an Arrayunless its type is ArrayLiteralConvertible, so its supported type(s) must support this.

This extension has been moved into its own section as it is not critical to the proposal, however it does represent an advantage of the attribute based approach, and would be desirable to have if implementing it is sufficiently easy for it to be done at the same time.

<https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#alternatives-considered&gt;Alternatives considered

One alternative often mentioned is simply enabling the existing variadic declarations to be called with an array. However, this has the same issue with ambiguity to resolve, and leaves variadics as their own category of function, rather than unifying them with ordinary functions.

It is possible to both add the @variadic attribute and retain the current syntax as a shorthand, however if the proposed extension is implemented this would discourage consideration of the best collection type to use, and in general it would remove one advantage in removing this extraneous syntax.

The nuclear option is to remove variadics entirely; this is the preference of some (myself included) as it eliminates the inherent ambiguity of variadics in general, forcing explicit use of arrays and other types with no need for limitations, however there is sufficient support for variadics now that they exist that this option is unlikely to succeed.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

6

There is a lot of design overlap. That is the reason why I think we should vision variadics as a whole in its future rather than simply repaint … postfix to a type annotation keyword @variadics. This will only close the doors for some features we might want to add in a future version of Swift.

This seems like an entirely separate feature to me; unless the intention is to go back to the old style of treating function arguments as a tuple I don't see why they should need to be related?

This was my first thought as well: imho it doesn't make sense to discard a good idea because of a vague hope that there might be something better (in, I'd expect, two or three years from now…).

Maybe you could explain a little bit how the feature you are hoping for should work, and why there would be interference?

7

This was my first thought as well: imho it doesn't make sense to discard a good idea because of a vague hope that there might be something better (in, I'd expect, two or three years from now…).

I feel the same way.

Currently, Swift’s variadic parameters are just a way to call a function without brackets around its arguments. It is not useful and frankly a bit deceptive compared to what other languages proposes. Keeping them as-is until something that won’t happen before swift 5 at best is a pity.

I mostly design embedded domain specific languages, and this proposal enables very interesting perspective in that regard.

Thanks,
Dimitri