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 > <[email protected]> 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 > > <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> > Author: Haravikk <https://github.com/haravikk> > Status: Awaiting review > Review manager: TBD > > > <https://github.com/Haravikk/swift-evolution/blob/master/proposals/nnnn-variadics-as-attribute.md#introduction>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>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>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>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>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>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>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>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>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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
