|
27 | 27 | - [Same-shape requirements](#same-shape-requirements)
|
28 | 28 | - [Restrictions on same-shape requirements](#restrictions-on-same-shape-requirements)
|
29 | 29 | - [Value parameter packs](#value-parameter-packs)
|
30 |
| - - [Local value packs](#local-value-packs) |
31 | 30 | - [Effect on ABI stability](#effect-on-abi-stability)
|
32 | 31 | - [Alternatives considered](#alternatives-considered)
|
33 | 32 | - [Modeling packs as tuples with abstract elements](#modeling-packs-as-tuples-with-abstract-elements)
|
|
37 | 36 | - [Magic builtin `map` method](#magic-builtin-map-method)
|
38 | 37 | - [Future directions](#future-directions)
|
39 | 38 | - [Variadic generic types](#variadic-generic-types)
|
| 39 | + - [Local value packs](#local-value-packs) |
| 40 | + - [Explicit type pack syntax](#explicit-type-pack-syntax) |
40 | 41 | - [Pack iteration](#pack-iteration)
|
41 | 42 | - [Pack element projection](#pack-element-projection)
|
42 | 43 | - [Dynamic pack indexing with `Int`](#dynamic-pack-indexing-with-int)
|
@@ -553,18 +554,6 @@ func forward<each U>(u: repeat each U) {
|
553 | 554 | }
|
554 | 555 | ```
|
555 | 556 |
|
556 |
| -### Local value packs |
557 |
| - |
558 |
| -The notion of a value parameter pack readily generalizes to a local variable of pack expansion type, for example: |
559 |
| - |
560 |
| -```swift |
561 |
| -func variadic<each T>(t: repeat each T) { |
562 |
| - let tt: repeat each T = repeat each t |
563 |
| -} |
564 |
| -``` |
565 |
| - |
566 |
| -References to `tt` have the same semantics as references to `t`, and must only appear inside other pack expansion expressions. |
567 |
| - |
568 | 557 | ## Effect on ABI stability
|
569 | 558 |
|
570 | 559 | This is still an area of open discussion, but we anticipate that generic functions with type parameter packs will not require runtime support, and thus will backward deploy. As work proceeds on the implementation, the above is subject to change.
|
@@ -670,6 +659,28 @@ The downsides of a magic `map` method are:
|
670 | 659 |
|
671 | 660 | This proposal only supports type parameter packs on functions. A complementary proposal will describe type parameter packs on generic structs, enums and classes.
|
672 | 661 |
|
| 662 | +### Local value packs |
| 663 | + |
| 664 | +This proposal only supports value packs for function parameters. The notion of a value parameter pack readily generalizes to a local variable of pack expansion type, for example: |
| 665 | + |
| 666 | +```swift |
| 667 | +func variadic<each T>(t: repeat each T) { |
| 668 | + let tt: repeat each T = repeat each t |
| 669 | +} |
| 670 | +``` |
| 671 | + |
| 672 | +References to `tt` have the same semantics as references to `t`, and must only appear inside other pack expansion expressions. |
| 673 | + |
| 674 | +### Explicit type pack syntax |
| 675 | + |
| 676 | +In this proposal, type packs do not have an explicit syntax, and a type pack is always inferred through the type matching rules. However, we could explore adding an explicit pack syntax in the future: |
| 677 | + |
| 678 | +```swift |
| 679 | +struct Variadic<each T> {} |
| 680 | + |
| 681 | +extension Variadic where each T == {Int, String} {} // {Int, String} is a concrete pack |
| 682 | +``` |
| 683 | + |
673 | 684 | ### Pack iteration
|
674 | 685 |
|
675 | 686 | All list operations can be expressed using pack expansion expressions by factoring code involving statements into a function or closure. However, this approach does not allow for short-circuiting, because the pattern expression will always be evaluated once for every element in the pack. Further, requiring a function or closure for code involving statements is unnatural. Allowing `for-in` loops to iterate over packs solves both of these problems.
|
|
0 commit comments