Le groupe a donc pris position dans une publication à l’intention du comité de normalisation du langage pour présenter une vision d’évolution du langage centrée sur un certain nombre d’axes dont la performance, la simplicité et la sécurité. Les auteurs suggèrent donc l’abandon de la rétrocompatibilité. De façon précise, la compatibilité qu’elle soit ascendante ou descendante ne fait pas partie de leur plan ; la stabilité de l’interface binaire-programme (ABI) non plus.
« D’après notre expérience, maintenir la stabilité de l'ABI pour les builds de haut niveau représente une charge de conception importante et permanente. Cela devient un obstacle à l'évolution, qui est l'un de nos objectifs déclarés », indiquent-ils. Ils proposent plutôt des migrations d’une version du langage à une autre comme réponse à l’abandon de la compatibilité. C’est sur la base de leur expérience de l’évolution logicielle au fil du temps et de la pertinence d’un modèle qui consiste à gérer le développement en direct sur une base de code unique qu’ils justifient ce positionnement.
En sus, le groupe d’ingénieurs envisage de laisser de côté le modèle de liaison standard et d’introduire la nécessité de procéder à des mises à jour complètes des chaînes d’outils pour chaque nouvelle version du langage C++. D’importants pans de la proposition qui s’inspire des cas d’usage (du langage C++) des auteurs ont fait l’objet de présentation lors de l’édition 2019 de la conférence CppCon.
La proposition a du sens pour des développeurs C++ lancés sur des projets à la durée de vie relativement courte comme ceux de la filière des jeux vidéo. On peut anticiper sur ceci que les bénéfices qu’ils sont susceptibles de tirer des améliorations apportées au langage devraient beaucoup plus peser sur la balance que les coûts de migration qui ont cours avec l’approche actuelle. À contrario, pour des projets qui ont déjà une certaine maturité, cela ne semble pas convenir. En effet, il n’y a pas d’importants ajouts de code nouveau et donc on entrevoit mal en quoi les améliorations du langage peuvent être d’un quelconque profit.
La sortie du groupe d’ingénieurs dont certains travaillent pour des entreprises comme Google laisse entrevoir des divisions qui couvent au sein de la communauté C++. « Nous pensons que de nombreuses questions qui divisent le comité proviennent d'un désaccord en lien avec les priorités », écrit-il. Le groupe de 17 souligne que son positionnement a pour but de faire savoir ce qu’il a comme attentes vis-à-vis du C++ en tant que langage de programmation système à hautes performances. Il n’insiste pas pour obtenir un consensus sur ces points dans l’immédiat.
Source : open-standard
Et vous ?
Voyez-vous aussi la compatibilité entre versions du langage comme un frein à l’évolution du C++ ?
En quoi un fork orienté selon cette proposition serait-il pertinent de votre point de vue ?
À quel type d’organisations pourraient profiter les évolutions proposées par les auteurs ?
Voir aussi :
De C++14 à C++17, qu'est-ce qui a changé avec la nouvelle version du langage C++ : un document de la Standard C++ Foundation
La spécification de la nouvelle version du langage C++ (C++17) est finalisée quelles sont les nouveautés introduites ?
Le premier brouillon de la prochaine révision du standard C, le C2x, est publié et met l'accent sur la compatibilité du langage
Internet aurait de sérieux problèmes à cause de langages comme C et C++ favorisant la survenue de failles mais peu de développeurs s'en soucieraient