Value and type parameter packs. #1956
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PsychoH13
reviewed
Feb 24, 2023
PsychoH13
reviewed
Feb 24, 2023
PsychoH13
reviewed
Feb 24, 2023
PsychoH13
reviewed
Feb 24, 2023
xwu
reviewed
Mar 6, 2023
proposals/NNNN-parameter-packs.md
Outdated
| * There are two very different models for working with packs; the same conceptual expansion has very different spellings at the type and value level, `repeat Wrapped<each T>` vs `values.map { Wrapped($0) }`. | ||
| * Magic map can only be applied to one pack at a time, leaving no clear way to zip packs without adding other builtins. A `zip` builtin would also be misleading, because expanding two packs in parallel does not need to iterate over the packs twice, but using `zip(t, u).map { ... }` looks that way. | ||
| * The closure-like syntax is misleading because it’s not a normal closure that you can write in the language. This operation is also very complex over packs with any structure, including concrete types, because the compiler either needs to infer a common generic signature for the closure that works for all elements, or it needs to separately type check the closure once for each element type. | ||
| * `map` would still need to be resolved via overload resolution amongst the existing overloads, so this approach doesn't help much with the type checking issues that `...` has. |
There was a problem hiding this comment.
Possibly slot the alternatives to the decisions made for the "open questions" mentioned above down here.
Co-authored-by: Remy Demarest <[email protected]>
hborla
force-pushed
the
parameter-packs
branch
3 times, most recently
from
0bc5694 to
5a6c08e
Compare
beccadax
reviewed
Mar 9, 2023
xedin
reviewed
Mar 19, 2023
proposals/NNNN-parameter-packs.md
Outdated
| - Substituting `each T := {Int}` into `(repeat each T)`. | ||
| - Substituting `each T := {}` into `(Int, repeat each T)`. | ||
|
|
||
| Though unwrapping single-element tuples complicates type matching, surfacing single-element tuples in the programming model would icnrease the surface area of the language. One-element tuples would need to be manually unrwapped with `.0` or pattern matching in order to make use of their contents. This unwrapping would clutter up code. |
xedin
reviewed
Mar 19, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Forum pitches:
With a dedicated syntax discussion at:
I originally wrote a prospective vision for variadic generics, but it turned out to be more like an extended future directions writeup, and much of the content has been folded into this pitch.