Pourquoi Swift a-t-il besoin de tables de témoins?

J'essaie de lire les détails de l'implémentation de Swift, et une chose que je ne peux pas comprendre, ce sont ses "tables témoins". Il semble que ce soit un pointeur vtable distinct utilisé pour les structures.

Mais pourquoi en auriez-vous besoin? Les structures sont copiées par valeur, donc vous savez déjà au moment de la compilation de quel type elles sont. Donc, ne coderiez-vous pas simplement la méthode à appeler et en finir avec elle? Pourquoi effectuer une répartition virtuelle sur ces méthodes?

Les structures peuvent implémenter des interfaces, appelées protocoles dans Swift. Vous pouvez avoir un paramètre, une variable ou un champ / membre qui est un protocole et, parce que plusieurs structures différentes, sans parler des classes, peuvent implémenter ce même protocole, une fois que vous passez (ou affectez) une structure à un paramètre de protocole (ou variable ou champ), dont la structure pourrait avoir été "perdue" (re: temps de compilation) et la table témoin du protocole entre en jeu (re: runtime).

Vous pouvez en savoir plus sur la disposition de la mémoire Swift .

La même chose se produit en C #, que je connais mieux. Une structure passée ou affectée à une variable d'interface ou à un champ / membre est encadrée, et la représentation encadrée de la structure correspond à celle des représentations de classe, ce qui signifie qu'il existe une table pour les structures encadrées.

Je m'attendrais à ce que C # et Swift effectuent des appels directs lorsque l'élément est connu au moment de la compilation en tant que struct, et utilisent la répartition vtable quand au moment de la compilation, l'élément n'est connu que comme une interface.