Thinking out loud…
There are two possibilities:
tuple is just a slightly odd version of
Array. Call this the Python approach.
tuple is a concept and mechanism thereof for implementing ‘anonymous’ structs.
The first approach is evidently doable, but it feels like it’s cheapening tuples to use them that way. Assuming variadic generics and some other future enhancement that lets you specify length constraints on collections, tuple becomes largely redundant amongst collections.
The second seems more interesting - and is explicitly the intent in Swift, per the Swift Language Reference:
A compound type is a type without a name, defined in the Swift language itself. There are two compound types: function types and tuple types.
The principle chosen is that tuple is not in the same vein as Array or other collections; it is a metatype. It essentially produces types that are identified not by an explicit name but by the number & type of their parameters.
Given that, I’m a little leery about assuming functionality (re. extensions or similar) across all tuples blindly, in the same way I’d be very judicious about being able to extend
struct as universal bases. How can you possible know, at that scope, what the intent & desires are of every implementation of those metatypes? To be clear, you cannot today extend
AnyClass - in fact for the latter the compiler error message explicitly notes that extending metaclasses is not permitted. Yet, anyway.
It feels like it needs a different mechanism. Something that is explicitly about metatypes - and would presumably also allow extending
AnyClass, etc by the same token - so as to avoid confusion (and likely to handle the extra complexities of the meta layer).
As this relates to this pitch & thread, I feel like this suggests that an inverse approach - involving some variadic generics support in future - isn’t the right direction (which is not to dissuade or detract from the immense utility of variadic generics in other contexts, to be clear). Allowing initialisation (with default init synthesis etc per normal) from specific tuple types (based on e.g. matching member variable count & types) seems more coherent, and in line with tuple’s apparent purpose.
That said, I am a bit worried about a proliferation of anonymising code based on this proposed enhancement. Using tuples as a ‘cheat’ to essentially just bypass argument naming seems subversive. Especially since you don’t have to require named arguments, as the author of a callable, so (
.init aside) you already can abbreviated your code if you wish. Maybe effort is best spent making invocation of the function compound type briefer (e.g. the
Similarly I’m a little worried about the use of anonymous types in generics, such as for dictionary keys. Doesn’t that weaken the type system by making it much easier to accidentally pass in a completely semantically unrelated tuple merely because they happen to have the same number & type of arguments? Are tuples appropriate for such use? This is giving me uncomfortable flashbacks to countless Python bugs resulting from this practice.