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.
Tu as raison mais c’est un argument de mathématicien / formaliste. Que ça ne résolve pas tous les problèmes ne veut pas dire que ça n’en résout pas une bonne partie. L’analyse statique de code n’est pas de la preuve formelle, la vérification statique de contrats rentre dans cette catégorie : trouver un maximum (≠ toutes) d’erreurs à la compilation.
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.
Je ne connaissais pas cet usage. En quoi est-ce différent de simplement définir l’opérateur d’affectation ? (en considérant que les types sont par défaut non-copiables – j’avais compris que c’était le cas en rust).
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).
Oui et non. L’idée des concepts est de formaliser les dépendances que peuvent avoir des classes / algorithmes génériques, en partie pour produire de meilleures messages d’erreur, en partie parce que rajouter de la sémantique est généralement une bonne idée. D’ailleurs, la doc de la STL fait depuis très longtemps (au moins depuis C++03) référence à ces concepts, même s’ils n’existent pas dans le langage. Mais les concepts, tels que je les ai toujours vu présentés, ne se substituent pas au « duck-typing ». C’est à dire que le fait qu’un type soit compatible avec un concept sera déterminé automatiquement par le compilateur. C’est d’ailleurs une partie très problématique qui provoque le report des concepts d’année en année, sachant que le bénéfice final n’est pas si évident (meilleurs messages d’erreur, mais c’est à peu près tout).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Premières impressions
Posté par whity . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 2.
Tu as raison mais c’est un argument de mathématicien / formaliste. Que ça ne résolve pas tous les problèmes ne veut pas dire que ça n’en résout pas une bonne partie. L’analyse statique de code n’est pas de la preuve formelle, la vérification statique de contrats rentre dans cette catégorie : trouver un maximum (≠ toutes) d’erreurs à la compilation.
Je ne connaissais pas cet usage. En quoi est-ce différent de simplement définir l’opérateur d’affectation ? (en considérant que les types sont par défaut non-copiables – j’avais compris que c’était le cas en rust).
Oui et non. L’idée des concepts est de formaliser les dépendances que peuvent avoir des classes / algorithmes génériques, en partie pour produire de meilleures messages d’erreur, en partie parce que rajouter de la sémantique est généralement une bonne idée. D’ailleurs, la doc de la STL fait depuis très longtemps (au moins depuis C++03) référence à ces concepts, même s’ils n’existent pas dans le langage. Mais les concepts, tels que je les ai toujours vu présentés, ne se substituent pas au « duck-typing ». C’est à dire que le fait qu’un type soit compatible avec un concept sera déterminé automatiquement par le compilateur. C’est d’ailleurs une partie très problématique qui provoque le report des concepts d’année en année, sachant que le bénéfice final n’est pas si évident (meilleurs messages d’erreur, mais c’est à peu près tout).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0