Je suis assez en désaccord avec ce post qui présente pour moi une vue biaisée de la situation. Même si je n'étais pas à la dernière réunion, j'ai suivi d'assez près son contenu.
la spécification des Concepts a été publiée le 15 novembre 2015, laissant peu de temps pour un retour efficace et fiable
La spécification des concepts existe depuis longtemps... C'est le fait que cette spécification soit sous forme de TS qui est récent. Même si le design a commencé bien avant, la première spécification existe depuis janvier 2014. Elle a évolué, certes, mais si on va par là, toutes les propositions évoluent, c'est leur objectif, et si on imposait à toute évolution une période de non évolution de plusieurs années avant d'être acceptées, on n'aurait rien dans C++17.
la seule implémentation est dans une version non publiée de GCC ;
Version qui ne pouvait pas être publiée, puisque les concepts ne sont pas dans le langage.... C'est l’œuf et la poule... Et c'était l'intérêt du TS que de rassurer les fabricants de compilateurs à faire l'effort d'implémentation avant la standardisation. Et il faut savori que de nombreuses fonctionnalités du langage ne sont que dans des versions non publiées avant d'être acceptées (certaines ne sont même pas implémentées dans leur forme finale...).
l’implémentation réalisée dans GCC a été réalisée par l’auteur de la spécification. Il n’y a donc pas eu d’avis externe sur la question de l’implémentation dans GCC ou dans les autres compilateurs ;
C'est le cas pour l'immense majorité des nouvelles fonctionnalités du langage. Et je n'ai jamais entendu cet argument utilisé pour autre chose que les concepts... Pour les autres cas, une question est récurrente est "Est-ce que ça a été implémenté?". Pour les concepts, il semblerait que la question soit "Est-ce que ca a été implémenté 3 fois par 3 équipes différentes dont aucune n'a le droit de contenir l'auteur principal de la proposition?"...
seuls quelques projets utilisent les concepts, mais la spécification n’a pas été assez mise à l’épreuve dans des cas réels ;
Et comment pourrait-elle l'être plus, tant que la proposition n'est pas acceptée ? Elle a été utilisée dans divers contextes, le contexte manquant le plus gênant étant la STL. Mais des grandes bibliothèques l'ont utilisée (range, par exemple)
la spécification ne fournit pas de bibliothèque de définitions de concepts. Donc il n’est pas possible de savoir si l’écriture d’une telle bibliothèque est possible.
C'est un point gênant mais hélas classique. Les gens qui travaillent sur le langage et ceux qui travaillent sur la bibliothèque sont différents, et tant qu'une fonctionnalité n'a pas été acceptée dans la langage, implémentée dans plusiuers compilateurs, les bibliothèques ont du mal à suivre. Par exemple, plusieurs années après la mise en place de
noexcept, on ne savait toujours pas sur quelles fonctions de la bibliothèque mettre
noexcept ou pas. Même chose pour
constexpr qui est seulement en train d'être ajouté à la bibliothèque standard.
les Concepts apportent une nouvelle écriture pour les templates. Toutefois, une fonction template abrégée peut être identique à une fonction non template. Le type serait le seul indicateur pour savoir si la fonction est non template ou si elle est template :
C'est le cas depuis le début, ça a été discuté et accepté. Après, certains n’aiment pas, mais à part rouvrir sans cesse les vieux débats...
Il est courant en C++ de ne pas pouvoir dire ce qu'est un code sans connaître le contexte. Si je dis
1 2
| void f(double d) {};
f(2); |
Je ne peux pas dire si cette fonction f sera appelée sans savoir s'il n'y a pas aussi visible dans le scope une autre fonction qui serait préférée. C'est la base de la surcharge, et ça ne gêne personne.
Et bien, dans le même ordre d'idée, si je vois
void f(Container const &c), je ne peux pas savoir sans un peu de contexte si je définis une fonction ou un template, mais :
- Généralement, je connais le contexte, et je peux dire par exemple que Container est un concept, et donc que je définis un template, mais que
f(vector<int> const &v) va définir une fonction.
- Le nom lui même doit m'aider
- Et la plupart du temps, je m'en moque totalement de savoir si une fonction est un template ou pas. J'ai sous la main en conteneur (sans savoir forcément son type exact, il est peut-être dans une variable auto initialisée par un retour de fonction, ou dans un argument template), je peux appeler f, c'est tout ce qui compte.
les Concepts sont attendus pour améliorer les messages d’erreur. Toutefois, l’utilisation erronée des Concepts peut apporter des erreurs encore plus dense qu’à l’accoutumée lié à la surcharge des fonctions ;
Je manque de recul sur ce point (toujours pareil, tant qu'on ne l'a pas vraiment dans un compilo qu'on utilise quotidiennement...), mais :
- Ce n'est pas le cas le plus courant
- Lire une longue liste de surcharge reste au niveau sémantique de l'interface. Pour les gens ayant l'habitude de plonger dans l'implémentation, peut-être que c'est un peu plus long, mais pour les gens voulant rester au niveau de l'interface, c'est mieux !
- Je ne doute pas qu'avec le temps, les compilateurs pourront affiner les messages d'erreur liés aux concepts (par exemple, lister en premier parmi les surcharges celle qui était le plus proche de passer, et donc la plus susceptible d'être la bonne).
de nombreuses autres questions ont été soulevées et ne pourront être répondues qu’à travers des tentatives d’utilisations.
Et ces tentatives ne pourront avoir lieu que quand les compilateurs proposeront cette fonctionnalité. Et qu'ils la proposeront vraiment, pas avec un flag "expérimental" et d'autres joyeusetés qui empêcheraient les gens de l'utiliser dans un vrai contexte professionnel. J'espère vraiment que la présence du TS ira dans cette direction... Je ne doute pas qu'il y aura des petits problèmes avec les concepts... Il y en a eu avec toutes les grosses fonctionnalités du langage. La move sémantic était totalement bancale bien après qu'elle ait été mise dans la langage, les lambda étaient incomplets...
Le problème, c'est qu'il y a un risque à ne pas livrer les concepts qui est pour moi plus important que le risque actuel de livrer des concepts imparfaits. Pour une autre vision sur le sujet, je vous propose de lire
http://www.open-std.org/jtc1/sc22/wg...6/p0225r0.html
8 |
0 |