C'est vrai que tu restreins (c'est le but en fait), après est-ce que c'est "arbitraire" ? Comme tu le dis toi même dans ton message la simple compatibilité syntaxique ne suffit à savoir si on peut réellement substituer le type. On peut imaginer par exemple un type de liste et un type ensemble qui possèdent la même interface, seulement l'opération ajout n'est pas substituable car si l’élément existe déjà dans le conteneur on l'ajoute quand même dans le cas de la liste mais on ne l'ajoute pas dans le cas de l'ensemble.
La programmation par contrat ne résout pas ce problème (en tout cas dans son acceptation classique) car comparer des contrats (des prédicats mathématiques en fait) n'est pas décidable. De plus les contrats sont en général optionnels et ce n'est pas si simple que cela de formaliser le comportement des fonctions.
De plus tu peux imaginer des trait (des interfaces quoi) qui servent seulement à restreindre sans apporter des méthodes. Par exemple les std::marker dans la lib standard te permettent de specifier ce qu'il est possible de faire avec un type. Par exemple si std::marker::Copy est implémenté cela signifie qu'il est légal de se contenter de faire une copie du type pour obtenir un copie (pas de dépendance à copier en plus), pour autant Copy n'a aucune méthode attachée. On voit bien dans ce cas là que le trait sert à exprimer les intentions des développeur et les informations dénoté ne peuvent pas être reconstruite par ailleurs.
Enfin, c'est principalement l’absence d'un tel mécanisme qui rend les erreurs des templates C++ aussi verbeux. Car le compilateur n'a aucun moyen de faire des vérifications autrement qu'en essayant d'instancier réellement le template et de voir si ça marche. D'ailleurs ils veulent le rajouter dans la prochaine version de C++ sous le nom de "concepts" (j'imagine que c'est dans une version différente de ce qui avait été proposé et refusé pour C++11).
[^] # Re: Premières impressions
Posté par Joris R (site web personnel, Mastodon) . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
C'est vrai que tu restreins (c'est le but en fait), après est-ce que c'est "arbitraire" ? Comme tu le dis toi même dans ton message la simple compatibilité syntaxique ne suffit à savoir si on peut réellement substituer le type. On peut imaginer par exemple un type de liste et un type ensemble qui possèdent la même interface, seulement l'opération ajout n'est pas substituable car si l’élément existe déjà dans le conteneur on l'ajoute quand même dans le cas de la liste mais on ne l'ajoute pas dans le cas de l'ensemble.
La programmation par contrat ne résout pas ce problème (en tout cas dans son acceptation classique) car comparer des contrats (des prédicats mathématiques en fait) n'est pas décidable. De plus les contrats sont en général optionnels et ce n'est pas si simple que cela de formaliser le comportement des fonctions.
De plus tu peux imaginer des trait (des interfaces quoi) qui servent seulement à restreindre sans apporter des méthodes. Par exemple les std::marker dans la lib standard te permettent de specifier ce qu'il est possible de faire avec un type. Par exemple si std::marker::Copy est implémenté cela signifie qu'il est légal de se contenter de faire une copie du type pour obtenir un copie (pas de dépendance à copier en plus), pour autant Copy n'a aucune méthode attachée. On voit bien dans ce cas là que le trait sert à exprimer les intentions des développeur et les informations dénoté ne peuvent pas être reconstruite par ailleurs.
Enfin, c'est principalement l’absence d'un tel mécanisme qui rend les erreurs des templates C++ aussi verbeux. Car le compilateur n'a aucun moyen de faire des vérifications autrement qu'en essayant d'instancier réellement le template et de voir si ça marche. D'ailleurs ils veulent le rajouter dans la prochaine version de C++ sous le nom de "concepts" (j'imagine que c'est dans une version différente de ce qui avait été proposé et refusé pour C++11).