From 453683bf44f2112719802eaac2b332d49eebd640 Mon Sep 17 00:00:00 2001 From: Yong He Date: Mon, 19 Aug 2024 15:03:56 -0700 Subject: Tuple swizzling, concat, comparison and `countof`. (#4856) * Tuple swizzling and element access. * Update proposal status. * Cleanup. * Fix merrge error. * Address review. --- docs/proposals/008-tuples.md | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) (limited to 'docs/proposals/008-tuples.md') diff --git a/docs/proposals/008-tuples.md b/docs/proposals/008-tuples.md index b1e62596f..efbcb7d28 100644 --- a/docs/proposals/008-tuples.md +++ b/docs/proposals/008-tuples.md @@ -11,9 +11,11 @@ Status Author: Yong He -Implementation: In-progress. +Status: Implemented. -Reviewed by: N/A +Implementation: [PR 4856](https://github.com/shader-slang/slang/pull/4856). + +Reviewed by: Jay Kwak, Kai Zhang, Ariel Glasroth. Background ---------- @@ -32,7 +34,7 @@ __generic __magic_type(TupleType) struct Tuple { - __intrinsic_op($(0)) + __intrinsic_op($(kIROp_MakeTuple)) __init(expand each T); } ``` @@ -77,15 +79,8 @@ Tuple concat(Tuple { return makeTuple(expand each first, expand each second); } -Tuple concat(Tuple first, expand each U second) -{ - return makeTuple(expand each first, expand each second); -} ``` -Note that we can't have an overload that takes a type pack and append it to the beginning of a tuple yet, because we -currently don't support having type pack arguments that aren't at the end of an argument list. - ### Counting @@ -134,4 +129,12 @@ Should we automatically treat `Tuple` type to conform to any interface `IFoo` if `IFoo`? We can't because this is not well-defined. For example, if `IFoo` has a method that returns `int`, should the tuple type's equivalent method return `Tuple` or just `int`? In some cases you want one but other times you want the other. And if the method returns a tuple, it is no longer consistent with the base interface -definition so this is all ill-formed. \ No newline at end of file +definition so this is all ill-formed. + +We also considered having an overload of `concat` that appends individual elements to the end of a tuple, such as: +``` +Tuple concat(Tuple t, each U values); +``` +However, this could lead to surprising behavior when the user writes `concat(t0, t1, t2)` where t1 and t2 are also tuples. +Having this overload means the result would be `(t0_0, t0_1, ... t0_n, t1, t2)` where the user could be expecting `t1` and `t2` +to be flattened into the resulting tuple. To avoid this surprising behavior, we decide to not include this overload in stdlib. \ No newline at end of file -- cgit v1.2.3