How can I determine the type of a tuple's elements directly from its type name in Swift?

Question

I have been exploring different abstractions in Swift, and I found myself stumped on how to determine the type of a tuple's element from its own type. I know the compiler and Xcode are quick to provide such information to me, the coder, and I know how to use type(of:) on the elements of a tuple variable or constant, but I cannot seem to figure out how to do it from code using only the tuple type.

Here is my question using incomplete code:

// Somewhere else in the code...
typealias NamedTuple = (/*someunknowntype*/, /*someotherunknowntype*/)

// Later in the code...
let tupleType = NamedTuple.self // repetitive, I know... but I know how to get its own type
let tupleElement0Type = // <-- How do I get this from the NamedTuple alias?

I cannot seem to discover any documentation that mentions a way to access a tuple's elements from its type name or literal format, although the latter would be silly.

I already know how to work around such issues using generic solutions. I am just looking for something straight forward, like with .self on a type name or alias.

I can already get the element types of arrays (ArrayType.Element.type) and dictionaries (Dictionary.Key.self and Dictionary.Value.self), but those are obviously through their typealias properties.

Does anyone know how to type the elements of a type directly from its name or alias? Or, at a minimum, from collections types other than an Array or a Dictionary?

Planography

I'm not familiar with Swift but this link has some relevant discussion – Allpurpose

@AbdulAzizBarkat That link is very helpful in sending me down the correct path. I will have to research it more, but it may lead me to an answer. If I find a solid answer, I will post it here. Your link led me to this link github.com/apple/swift/blob/master/docs/ABI/…, which, although dated, has a plethora of relevant info. Thanks! – Planography

This looks like an XY problem. Can you give details how would you use this information? Some code snippets to exemplify this would help, even if they don't compile. – Springhouse

Agreed with @Springhouse - I was also thinking of XY. In particular, could you please clarify your statement "I already know how to work around such issues using generic solutions". Can you show us how you would solve it - rather than just saying you know. Also, explain then why you are not happy with that solution and why you want something else. – Bashee

Why would this need any more motivation than I can get the element type of an array element like ArrayType.Element.type how do I get the element type of the first element of a tuple? I don't see why the latter needs more motivation and is an XY problem when the former clearly has a solution. – Girish

@Cristik, I believe I may have identified what you mean. I was not separating compile time type identities from runtime type identities. I will have to rethink and rewrite my question. I was trying to get something I thought would be easy to answer but where I could not find the documentation. – Planography

@CorneliusRoemer, I have been too wild in my experimentation. I know how to use generic syntax to create code without specifying a specific type, as long as protocols can match the code, but since Swift will not compile code without type matches, I was having difficulty figuring out the types of tuple elements for which I did not know the types. My experiment may have crossed between compile time type matching and runtime type identification in my experiment. I did not understand the differences well enough to pose a less ambiguous question. I did not know there was an ambiguity. Now I know. – Planography

@cafce25, I meant that because the type itself is named on that line, pulling its type Meta was, in a way, repetitive. What I have had trouble grabbing are the type metas for the elements of the tuple for type matching. As I have mentioned previous, I may have been mixing up compile time with runtime type matching. I have to improve my understanding of both. And since you are the third to teach me a new term, "XY problem," I will have to be more cognizant of such possible ambiguities in my thinking. – Planography

@Planography I'm sorry, that was not meant for you, I think this question is fine, not an XY Problem. – Girish