Consider I have two or more Tuples in a struct. from std.reflection import get_type_name def work_with_tuple[*elems: Movable](obj: Tuple[*elems]): print(get_type_name[type_of(obj)]()) struct Container[ Tuple1: Copyable, Tuple2: Copyable, ](ImplicitlyCopyable): def __init__(out sel…

Try from std.reflection import get_type_name def work_with_tuple[*elems: Movable](obj: Tuple[*elems]): print(get_type_name[type_of(obj)]()) struct Container[ Elems1: Variadic.TypesOfTrait[Movable], Elems2: Variadic.TypesOfTrait[Movable], ]: # Since T1 and T2 is known now, so we …

In C++, the following is easily achievable. Compiler Explorer #include <cstdio> #include <tuple> template <typename... Ts> void work_with_tuple(std::tuple<Ts...>&& obj) { printf("work_with_tuple"); } template <typename Tuple1_, typename Tuple2_> struct Container { using Tuple1 = Tuple1_; …

The reason this doesn’t work in Mojo is due to how the Mojo compilation model differs from the C++ one. In C++ you can write Container(Tuple1_&& v1, Tuple2_&& v2) { work_with_tuple(std::forward<Tuple1>(v1)); } because c++ doesn’t do any type checking of templated types/functions u…

I think it’s important to note here that this behavior difference from C++ is one of the reasons that Mojo compiles so much faster. Local reasoning is a super important policy for performance.

[image] nate: struct Container(ImplicitlyCopyable): def __init__(out self, v1: Tuple[...], v2: Tuple[...]): work_with_tuple(v1) work_with_tuple(v2) This doesn’t work. Things are passed to ctor with reasons. struct Container(ImplicitlyCopyable): var v1: ??? var v2:…

After playing around with this problem a little bit more during C++ compiling :sweat_smile: , I made some progress: from std.reflection import get_type_name def work_with_tuple[*elems: Movable](obj: Tuple[*elems]): print(get_type_name[type_of(obj)]()) struct Container[ T1: type_of(Tuple[.…

OK, more progress during more C++ compilation :sweat_smile: from std.reflection import get_type_name def work_with_tuple[*elems: Movable](obj: Tuple[*elems]): print(get_type_name[type_of(obj)]()) struct Container[ T1: type_of(Tuple[...]), # So type_of(Tuple[...]) is a Trait for TupleLike…

How to resolve unresolved parameter?

Mojo

jbemmel (Jeroen van Bemmel) April 9, 2026, 2:33pm 8

The ‘rebind’ would ideally be inferred

Topic		Replies	Views
Exploring Metaprogramming in Mojo Content	1	599	May 28, 2025
There is a tuple method of Python in document,but my compiler told me there is not Mojo	5	84	April 26, 2025
How to build an extendable parametric struct Mojo discussion , feature-request , 24_6	3	143	June 29, 2025
Trait with parametric associated alias with variadic Parameter Mojo	1	60	February 7, 2026
`obj[...]` syntax is "legacy" and should be removed Mojo	20	227	March 19, 2026

How to resolve unresolved parameter?

Related topics