Re: go 2.0

Tout ça a un cout bien réel, peu importe l’élégance théorique du concept.

D'un autre côté, l'absence d'une implémentation des types sommes dans le langage a un coût bien réel à chaque fois qu'un programme utilise la notion de type sommes (parfois sans le savoir): il devient nécessaire de passer par des encodages compliqués pour implémenter le concept en se passant du soutien du compilateur: détection d'erreur, avertissements divers et variés, syntaxes plus légères.

Un exemple concret, dernièrement je me suis amusé à écrire un binding OCaml pour Vulkan, dans l'API Vulkan on retrouve des structures comme

typedef struct VkPipelineColorBlendAttachmentState {
 VkBool32 blendEnable;
 VkBlendFactor srcColorBlendFactor;
 VkBlendFactor dstColorBlendFactor;
 VkBlendOp colorBlendOp;
 VkBlendFactor srcAlphaBlendFactor;
 VkBlendFactor dstAlphaBlendFactor;
 VkBlendOp alphaBlendOp;
 VkColorComponentFlags colorWriteMask;
} VkPipelineColorBlendAttachmentState;

Un problème pratique avec cette structure est que si blendEnable vaut false tous les autres champs n'ont aucune importance; mais c'est un point qu'il est impossible de voir dans le système de type, et il devient difficile de savoir si ne pas initialiser le champ alphaBlendOp est une erreur ou pas. Au contraire, dans un système de type avec des types sommes, il devient possible d'écrire

type VkPipelineColorBlendAttachmentStateCore =
| Diabled
| Enabled {
 srcColorBlendFactor: VkBlendFactor;
 dstColorBlendFactor: VkBlendFactor ;
 colorBlendOp: VkBlendOp;
 srcAlphaBlendFactor: VkBlendFactor;
 dstAlphaBlendFactor: VkBlendFactor;
 alphaBlendOp: VkBlendOp;
 colorWriteMask: VkColorComponentFlags;
}

et soudainement les cas d'ambigüités sur des champs non initialisés disparaissent.

Et ce n'est qu'un cas parmi d'autres, de réimplémentation locale de types sommes dans l'API Vulkan.